Re: cvs commit: apr/threadproc/unix proc.c

2002-01-26 Thread Jeff Trawick
[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 rid of

Re: [Fwd: Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c]

2001-10-19 Thread Jeff Trawick
(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 Oct 2001 13:02:25 -0700

Re: [Fwd: Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c]

2001-10-19 Thread William A. Rowe, Jr.
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 app. If

Re: [Fwd: Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c]

2001-10-19 Thread Ryan Bloom
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

Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c

2001-10-18 Thread Jeff Trawick
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

Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c

2001-10-18 Thread Greg Ames
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

Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c

2001-10-18 Thread Justin Erenkrantz
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 doc in

Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c

2001-10-18 Thread Ryan Bloom
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

Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c

2001-10-18 Thread Jeff Trawick
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 right

Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c

2001-10-18 Thread Jeff Trawick
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.

Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c

2001-10-18 Thread Ryan Bloom
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 WCOREDUMP(),

Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c

2001-10-16 Thread Ryan Bloom
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

Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c

2001-10-16 Thread Kevin Pilch-Bisson
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 Windows to have

Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c

2001-10-16 Thread Jeff Trawick
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 a

Re: cvs commit: apr/threadproc/unix proc.c

2001-10-15 Thread Jeff Trawick
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 able

[PATCH] Re: cvs commit: apr/threadproc/unix proc.c

2001-10-15 Thread Jeff Trawick
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

Re: cvs commit: apr/threadproc/unix proc.c

2001-10-13 Thread Justin Erenkrantz
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

Re: cvs commit: apr/threadproc/unix proc.c

2001-10-13 Thread Jeff Trawick
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 the log

Re: cvs commit: apr/threadproc/unix proc.c

2001-10-13 Thread Kevin Pilch-Bisson
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 SIGSEGV)...

Re: cvs commit: apr/threadproc/unix proc.c

2001-10-12 Thread Jeff Trawick
[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:31