apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: [Fwd: Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c]
Date Fri, 19 Oct 2001 15:47:08 GMT
On Friday 19 October 2001 07:45 am, Jeff Trawick wrote:

Expect a patch by Monday night.  I have in-laws in town this weekend.  :-)

> your opinion :)  mine differs; apr_wait_t (definitely should be called
> something else) is simply what information the os makes available
> regarding the dead child process
> we don't need the native status code to be what the program returned
> when it exited, because we provide that in a separate parameter
> > I am very much against changing the API of an APR function temporarily.
> > Returning the native exit code is not the correct solution to this
> > problem,
> > because that code can't really be used in a portable app.  If the idea
> > is to
> > go to three variables in the function, and then move back to two, then
> > just
> > go straight to two.  If the idea is to stick with three forever, then
> > -1.
> no, the idea wasn't to go from 3 to 2; I think all three pieces of
> information are necessary, but if you want to provide one of the
> pieces of information via a different mechanism, then by all means
> show us what you mean
> maybe somebody else can jump in here and offer some fresh ideas; maybe
> you (Ryan) would be able to find some time to come up with concrete
> suggestions for how to convey all the necessary information back to
> the app in a politically-correct manner
> we can't have an Apache beta until this stuff is resolved (I wouldn't
> veto a beta if just the WCOREDUMP() functionality is missing, but
> there must be a design in place to restore that in the short-term);
> maybe that will be enough to bring in some more attention/ideas

Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message