[EMAIL PROTECTED] writes:
> jerenkrantz02/01/24 18:21:43
>
> Modified:threadproc/unix proc.c
> Log:
> Fix leakage with fds with respect to pipes. dup2() should close the old
> file descriptor and this new one will be closed when we clean up the pipe.
This seems to be what got ri
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
Kevin Pilch-Bisson <[EMAIL PROTECTED]> 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
On Sat, Oct 13, 2001 at 02:06:30PM -0400, Jeff Trawick wrote:
> Justin Erenkrantz <[EMAIL PROTECTED]> 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 SIGSE
Justin Erenkrantz <[EMAIL PROTECTED]> 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
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
[EMAIL PROTECTED] writes:
> jerenkrantz01/09/21 09:14:50
>
> Modified:.CHANGES
>threadproc/unix proc.c
> Log:
> Simplify apr_proc_wait_all_procs and consolidate apr_proc_wait.
>
> Index: proc.c
> diff -u -r1.48 -r1.49
> --- proc.c 2001/09/20 08:59:
21 matches
Mail list logo
