At 02:19 PM 2/5/2003, Jeff Trawick wrote:
>William A. Rowe, Jr. wrote:
>
>>At 11:53 AM 2/5/2003, Jeff Trawick wrote:
>>
>>>on APR not providing a string which tells what type of processing failed:
>>>
>>>With no string from APR, you don't know if, for example, the failure was
>>>EPERM because
>>>
William A. Rowe, Jr. wrote:
At 11:53 AM 2/5/2003, Jeff Trawick wrote:
>on APR not providing a string which tells what type of processing failed:
>
>With no string from APR, you don't know if, for example, the failure
was EPERM because
>
>a) permissions on working directory were bad
>b) permissions
At 11:53 AM 2/5/2003, Jeff Trawick wrote:
>William A. Rowe, Jr. wrote:
>
>>At 08:59 AM 2/5/2003, Jeff Trawick wrote:
>>
>>I think that you, Justin, and I agree that there is no need for a feature
>>test macro. That's cool.
Yup - all on the same page here.
>>But what about simply an apr_proc_cre
--On Wednesday, February 5, 2003 12:53 PM -0500 Jeff Trawick
<[EMAIL PROTECTED]> wrote:
I'd like to see some +1s for this from others. I'm not sure that
it is a bug not to have the function. I'm not really opposed, I
simply would choose to continue adding process attributes rather
than more par
William A. Rowe, Jr. wrote:
At 08:59 AM 2/5/2003, Jeff Trawick wrote:
>Any concerns, particularly with respect to how the app determines if
the feature is available? I think it would be fine to make the
feature always available but to simply note that on some platforms the
application-specified
Greg Ames wrote:
> Alternatively, APR could allow the application to get called in the
> child process in the failure cases and allow it to do whatever is
> appropriate (log a message, synchronize with the parent process, etc.).
Couldn't the stat's, chdir's, etc. be done only after a failure to kee
At 08:59 AM 2/5/2003, Jeff Trawick wrote:
>Any concerns, particularly with respect to how the app determines if the
>feature is available? I think it would be fine to make the feature always
>available but to simply note that on some platforms the application-specified
>error function would nev
Jeff Trawick wrote:
On Unix, some failures of apr_proc_create() are not noticed in the
calling process and so apr_proc_create() returns APR_SUCCESS even though
it failed.
++1 in concept. It has bugged me for a long time that httpd 2.0 only logs
"Premature end of script headers" no matter what i
--On Wednesday, February 5, 2003 9:59 AM -0500 Jeff Trawick
<[EMAIL PROTECTED]> wrote:
Any concerns, particularly with respect to how the app determines
if the feature is available? I think it would be fine to make the
feature always available but to simply note that on some platforms
the applic
Jeff Trawick wrote:
Index: include/apr.h.in
===
RCS file: /home/cvs/apr/include/apr.h.in,v
retrieving revision 1.118
diff -u -r1.118 apr.h.in
--- include/apr.h.in22 Jan 2003 18:25:59 - 1.118
+++ include/apr.h.in5 Feb 2
Bill Stoddard wrote:
+1, this looks like very useful function. I would like to see a bit
more explanation in the child_errfn_set making it clear that this
function is used to accurately report failures in the 'exec' of a 'fork
& exec'. Also explicitly state that this function can only be used on
+1, this looks like very useful function. I would like to see a bit
more explanation in the child_errfn_set making it clear that this
function is used to accurately report failures in the 'exec' of a 'fork
& exec'. Also explicitly state that this function can only be used on
systems that use f
On Unix, some failures of apr_proc_create() are not noticed in the
calling process and so apr_proc_create() returns APR_SUCCESS even though
it failed.
Some of the potential failures could be discovered in the parent by
using extra syscalls (e.g., use stat to make sure the program actually
exis
13 matches
Mail list logo
