apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: Problem with apr_proc_wait and/or svn_io_run_cmd
Date Thu, 23 Jan 2003 13:11:45 GMT

Joe Orton wrote:

> On Wed, Jan 22, 2003 at 11:44:08PM -0500, Eric Gillespie wrote:
> >As an attempt to make this on-topic for both lists, i won't go
> >into how i discovered the bug.  I don't think it's necessary.
> >
> >Correctly using waitpid(2) involves checking for EINTR and trying
> >again.  That leads to common usage being something like this:
> That does look like a bug.
> ...
> >It looks like the APR equivalent is supposed to be:
> >
> >    do {
> >        apr_err = apr_proc_wait (&cmd_proc, &exitcode_val,
> >                                 &exitwhy_val, APR_WAIT);
> >    } while (APR_STATUS_IS_CHILD_NOTDONE (apr_err));
> >
> >Is that correct?
> I don't think so really: the child will only be "NOTDONE" if you pass in
> APR_NOWAIT; otherwise, the waitpid waits until the child *is* done.
> ...
> >It may be as simple as changing APR_STATUS_IS_CHILD_NOTDONE, in
> >which case apr_proc_wait doesn't need to change at all.  But i am
> >not sure that is the solution.  No matter what, svn_io_run_cmd
> >will need to change so that it repeats the apr_proc_wait call as
> >necessary (unless you want to make apr_proc_wait itself loop over
> >waitpid(2), which i think is NOT the way to go).
> My guess would be to make apr_proc_wait loop over waitpid whilst
> errno=EINTR; that's what the rest of APR does.  Though the interactions
> between waitpid and SIGCHLD here are a bit daunting, just from reading
> the Linux waitpid() man page.

most but not all of the rest of APR does that

the inconsistency is ugly, but being able to see EINTR is important

it can mean that certain apps can have simple signal handlers that only
have to set flags instead of having to longjmp out to avoid the APR
"while (EINTR)" loop

it can mean that certain apps have better performance because they didn't
have to add extra signalling mechanisms (e.g., extra pipe to poll on) since
a signal can break the app out of apr_accept() and allow the app to
check flags

non-portability sucks, but so does losing the ability to use key Unix
features...  cute doesn't matter if your program can't take advantage of
the design of the underlying system

compromise may be some attribute on APR object or flag on certain
APR functions to tell APR to surface the EINTR condition

View raw message