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...
