Re: [Chicken-users] process-wait

[Jörg F . Wittenberger]

On Sep 1 2011, address@hidden wrote:

> > The idea is to convert (process-wait pid #f) into
> > (process-wait pid #t) and block the current tread only
> > when the first result is zero.
>
> Sounds indeed frustrating. I've run across similar problems while writing 
> a multitasking web server. It uses process-fork to create child processes 
> which handle the client requests. Under Linux, the parent may wait, or 
> not, for the child to finish, If not, the child doesn't "go away"--it's a 
> "zombie"--until the parent ends, unless the default signal handler flags 
> are set to a NOWAIT value.

I'm pretty positive that this is not the issue.
Let me say: I'm trying to mimic a procedure, which is absolutely
stable working under rscheme (which is very similar wrt. threads).

Furthermore the details what those subprocesses do should not matter.
For the record: they try to set up and handle network connections.
Also I actually set up some safeguards to catch zombies.
But in fact I could even live with them.

> It's not entirely clear what your code is trying to do. I gather that 
> somehow child processes are created, and SRFI-18 threads are waiting for 
> a child to signal its termination.

Correct.  There are some 50-100 i/o subprocesses and - well -
more, many more chicken threads than absolutely required.

> If multiple processes are needed for the application, then some other 
> approach is probably going to be necessary. One thing I've experimented 
> with is using POSIX mmap and semaphore facilities. Mmap is already in the 
> posix unit. It's not too difficult to wrap native semaphore functions 
> with the Chicken FFI. Some preliminary testing suggests this works 
> adequately and doesn't require waiting on child processes.

Thanks for the idea!  I do have code working here, which runs
C library functions in POSIX threads (I'm using that to call
sqlite3, which would otherwise block chicken too; and that's
even worse because that sqlite3 runs on top of a sqlite3-vfs, which
in turn is served by the chicken side, thus it would deadlock
without POSIX threads in between).

Doing all waitpid operations in a POSIX thread could be helpful
if everything else fails.

At the other hand it looks like an overkill.

> Hope I haven't missed something you were getting at.

Not exactly.  But at this time my bet is different issue.
My hypothesis is that there's a garbage collection triggered
within the signal handler and this interferes with stack layout
or the other way around, the signal handler is run during gc.

I mean: why the hell does it work most of the time, even sustains
a killall to 50 subprocesses often enough and sometimes
just ends up looping.  (with gdb I found it in C_reclaim - no
surprise, but then it should continue at a point with the next
trace message, shouldn't it?)

thanks anyway

/Jörg
......