[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] process-wait

From: Jörg F . Wittenberger
Subject: Re: [Chicken-users] process-wait
Date: 01 Sep 2011 19:55:17 +0200

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]