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 chil
From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Friday, October 19, 2001 9:45 AM
>
> > 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
(sorry for the forward; my sendmail got sick for a while and was
discarding messages handed to it by my pop client :( )
Greg Ames <[EMAIL PROTECTED]> writes:
> Original Message
> Subject: Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c
> Date: Thu, 18 Oc
On Thursday 18 October 2001 12:15 pm, Jeff Trawick wrote:
> Ryan Bloom <[EMAIL PROTECTED]> writes:
> > I am missing something here. This patch requires us to use the
> > non-portable W* macros in Apache. That is wrong.
>
> This patch does not force an APR app to use any W* macros other than
> WCO
Ryan Bloom <[EMAIL PROTECTED]> writes:
> I am missing something here. This patch requires us to use the non-portable
> W* macros in Apache. That is wrong.
This patch does not force an APR app to use any W* macros other than
WCOREDUMP(), and most apps don't care about that.
>
Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> I think WIFSTOPPED needs to be checked (do all platforms have this?
> Linux does). But, I'm not sure that should return APR_CHILD_DONE or
> NOTDONE - since the process may resume later on. This gets hairy.
> Also, is returning APR_EGENERAL the righ
On Thursday 18 October 2001 10:44 am, Jeff Trawick wrote:
> Here is yet another patch. When compared with the previous patch,
> this one adds the native status to the parameter lists of
> apr_proc_wait() and apr_proc_wait_all_procs(). Fewer MPM changes are
> necessary.
>
> missing: fix the doc in
On Thu, Oct 18, 2001 at 01:44:08PM -0400, Jeff Trawick wrote:
> Here is yet another patch. When compared with the previous patch,
> this one adds the native status to the parameter lists of
> apr_proc_wait() and apr_proc_wait_all_procs(). Fewer MPM changes are
> necessary.
>
> missing: fix the d
Jeff Trawick wrote:
> I'm happy with the APR-ized notion of how-did-the-process-exit and
> what-is-the-signal-or-exit-code but throwing away the native status is
> a real problem.
[...]
> missing from patch:
> doc in header files, other mpms, apr/threadproc/foo, where foo !=
> unix, testing
>
Here is yet another patch. When compared with the previous patch,
this one adds the native status to the parameter lists of
apr_proc_wait() and apr_proc_wait_all_procs(). Fewer MPM changes are
necessary.
missing: fix the doc in apr_thread_proc.h
roll the changes into apr/threadproc/foo/
Ryan Bloom <[EMAIL PROTECTED]> writes:
> I would also get rid of the native exit code.
This is a real pain. Unfortunately, I only "felt" it and didn't have
any concrete examples until I got mostly done with a new patch :)
Consider the logic in Apache to see if a core dump occurred. This
isn't
On Tue, Oct 16, 2001 at 08:41:35AM -0400, Jeff Trawick wrote:
> Ryan Bloom <[EMAIL PROTECTED]> writes:
>
> > On Monday 15 October 2001 10:38 am, Jeff Trawick wrote:
> >
> > I seriously doubt that we want to extend the apr_proc_t type anymore.
> > Having
> > this type be complete has caused Wind
Ryan Bloom <[EMAIL PROTECTED]> writes:
> On Monday 15 October 2001 10:38 am, Jeff Trawick wrote:
>
> I seriously doubt that we want to extend the apr_proc_t type anymore. Having
> this type be complete has caused Windows to have to jump through hoops to
> keep track of processes correctly, and a
On Monday 15 October 2001 10:38 am, Jeff Trawick wrote:
I seriously doubt that we want to extend the apr_proc_t type anymore. Having
this type be complete has caused Windows to have to jump through hoops to
keep track of processes correctly, and adding more to it is a mistake IMO.
Also, I would
This patch implements (for Unix, at least) what I mentioned in a
previous post, namely, to make available all information about a
terminated child but to classify it so that a portable app doesn't
have to play games with WIFEXITED() et al.
As I mentioned before, I don't know if we're doing the rig
15 matches
Mail list logo