Justin Erenkrantz <[EMAIL PROTECTED]> writes: > On Fri, Oct 12, 2001 at 05:44:38PM -0400, Jeff Trawick wrote: > > no!!!!!!! Because of this, we're returning APR_CHILD_NOTDONE when a > > child exits due to a signal (like SIGSEGV)... thus Apache isn't able > > to see that the segfault happened and the log message is broken. > > > > The old code had this correct. If waitpid() returns >0, a child has > > finished. The WIF...() macros are just to find out how it finished > > (it chose to exit -- WIFEXITED, it got a signal -- WIFSIGNALED()). > > Um, okay. Is this acceptable? -- justin > > Index: threadproc/unix/proc.c > =================================================================== > RCS file: /home/cvs/apr/threadproc/unix/proc.c,v > retrieving revision 1.49 > diff -u -r1.49 proc.c > --- threadproc/unix/proc.c 2001/09/21 16:14:50 1.49 > +++ threadproc/unix/proc.c 2001/10/13 15:00:27 > @@ -390,9 +390,8 @@ > if (exitcode != NULL) { > *exitcode = WEXITSTATUS(exit_int); > } > - return APR_CHILD_DONE; > } > - return APR_CHILD_NOTDONE; > + return APR_CHILD_DONE; > } > else if (pstatus == 0) { > return APR_CHILD_NOTDONE;
The handling of the return code looks right, but as far as I can tell we're still missing the ability for the caller of apr_proc_wait_all_procs() (and thus the caller of ap_wait_or_timeout()) to know how the child exited, since exitcode is only updated if the child chose to exit. I don't think apr_wait_t pretends to be some sort of portable the-process-chose-to-exit-with-this-return-code value, so it seems fine to feed back the raw OS status as we did before, whether the process exited normally or due to a signal. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...