apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: cvs commit: apr/threadproc/unix proc.c
Date Mon, 15 Oct 2001 15:10:21 GMT
Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:

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

I think it was understood that they weren't portable (since apr_wait_t
was exposed).  I understand why you want a nice congealed exit code,
but you can't have such a thing without telling the user what you got
(well, since a segfault currently reports APR_CHILD_NOT_DONE I guess
you have that, sort-of).

I wish I knew the history of these APR interfaces, but I don't.  Why
do we bother to define apr_wait_t and thus expose these details to the
APR user, for example?

It would seem to me that more fields will be needed in the apr_proc_t
and we might as well get rid of the apr_wait_t parameter, since you
can't look at that portably without knowing how the process exited.

New fields in apr_proc_t, filled in by apr_proc_wait() and

1) apr_wait_t native_exit_status (on Unix, this is the complete encoded
2) some_enum exit_type           (normal-termination, uncaught-signal,
                                 stop-signal, whatever else)
3) union {
     int signal;                 (a terminating signal or stopping signal)
     int exit_code;
   } exit_status;

I included mention of stopping signals here.  I must confess that I
don't know why we care about stopped processes.

Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
             Born in Roswell... married an alien...

View raw message