On Sep 2 2011, Jörg F. Wittenberger wrote:
3. It might be all much easier to rearrange cicken different way to
allow real code in signal handlers. (mutex-unlock! is already
proven to be real code in that case, i.e., *will* hang eventually.)
...
This one does not try to handle POSIX
Jörg F. Wittenberger scripsit:
But wait: Jules is right: somehow there needs to be some arrangement
that there's a waitpid sure before the process exists on any other way
to prevent zombies on the system.
Does anyone have a suggestion how to assure that?
If the parent process calls
On Sat, Sep 03, 2011 at 10:30:24AM -0400, John Cowan wrote:
Jörg F. Wittenberger scripsit:
But wait: Jules is right: somehow there needs to be some arrangement
that there's a waitpid sure before the process exists on any other way
to prevent zombies on the system.
Does anyone have a
On Sep 3 2011, Alan Post wrote:
but it is important
to me to be able to wait for children I spawn and collect their exit
status--this is a feature I use and need to retain.
If the runtime is going to change the way that this works, I
still need the ability to check the status of my child
On Sep 2 2011, Jörg F. Wittenberger wrote:
3. It might be all much easier to rearrange cicken different way to
allow real code in signal handlers. (mutex-unlock! is already
proven to be real code in that case, i.e., *will* hang eventually.)
There is one better way (phenomenologically,
