apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Pilch-Bisson <ke...@pilch-bisson.net>
Subject Re: cvs commit: apr/threadproc/unix proc.c
Date Sat, 13 Oct 2001 21:14:10 GMT
On Sat, Oct 13, 2001 at 02:06:30PM -0400, Jeff Trawick wrote:
> Justin Erenkrantz <jerenkrantz@ebuilt.com> 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.
As the one who proposed this patch, I thought I should jump in here.

WIFEXITED and WEXITSTATUS are not portable.  Applications may need more detail
than simply whether it exited due to a signal or not.  For example, subversion
has a pre-commit hook which prevents a commit if it returns non-zero.  We need
to be able to determine the exact return value.  It is also useful when we run
programs such as diff and patch, which return diagnostics via the exit code.

Maybe this isn't the right way to go about it, but I think there does need to 
be a way of determining what the process chose to exit with.

> 
> -- 
> Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
>        http://www.geocities.com/SiliconValley/Park/9289/
>              Born in Roswell... married an alien...

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mime
View raw message