Re: [Chicken-users] Fwd: Re: process-wait

[Jörg F . Wittenberger]

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 signals in the original signal
> handler.  Instead the handlers are activated from ##sys#schedule.

It occurred to me that with my modifications (especially invoking the
signal handler code from ##sys#schedule) it would no longer be
required to call  C_raise_interrupt in the global_signal_handler
at all.  I tried: it sill works - and so much better than before.

Furthermore with this change to deal with child processes: just have
a thread waiting for the process to terminate (then process-wait-for-pid
case).  It will not block but see the process dying.

I guess I should clean up the code.

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?

Explicit termination would require knowledge about all processes started
so far (which have not been waited for).  This in turn would require
more changes to the posix unit (either maintain a list with process-fork
or even use a structure as process reference instead of the raw pid.
Both not too nice.

I'd rather knew about some posix magic I'm not aware off.  Does it exist?

Best regards

/Jörg
.....