Re: [A] Re: [Q] [PATCH] prog-modes: eiffel.el - Add function eif-debug
On 26 Jun 2002, Stephen J. Turnbull mused:
>>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
MS> is t when the process is a zombie? In my particular case, if
MS> XEmacs did a wait*() to cleanup the child, it wouldn't matter
MS> anyway. For some reason XEmacs is updating the display but
MS> not reaping dead children... :-(
SY> The first two people I'd be asking would be Ben Wing or Martin
SY> Buchholz. Unfortunately, Ben has just started a vacation in
SY> Italy and Martin is on a sabbatical of unknown duration.
Nix is the guy to ask, I think. He had a flurry of patches about race
conditions etc related to the process code. Kyle Jones had some
input, too.
Hm, well, I think I know what goes on here.
The process is reaped by a SIGCHLD handler (record_exited_processes(),
called by sigchld_handler() and by unix_reap_exited_processes()). As
such, if it's not reaped, then XEmacs hasn't noticed about it yet,
probably because the OS hasn't bothered to deliver a SIGCHLD, or XEmacs
has SIGCHLD blocked.
The process status itself is updated to Qstop principally in
unix_reap_exited_processes(), which is called from status_notify(),
which is called from the main event loop. Now I think about it this
seems rather broken because it means that PROCESS_LIVE_P will return t
(with all that that implies) between a process dying and the event loop
being called. Is there a reason why we don't change the status to Qexit
at the time the process dies?
(Note that the `old' method of determining if a process is dead (before
my patch), which was to look at its pipe_instream, was just as broken,
because that too was only updated in the main event loop.)
I can produce a patch if anyone cares enough ;}
--
`What happened?'
`Nick shipped buggy code!'
`Oh, no dinner for him...'