You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Branko Čibej <br...@xbc.nu> on 2002/07/03 00:36:25 UTC
Re: cvs commit: apr/threadproc/win32 proc.c
brane@apache.org wrote:
>brane 2002/07/02 15:25:52
>
> Modified: threadproc/win32 proc.c
> Log:
> Reverting the 1.76 and 1.77 changes, because they didn't work.
> The child handles weren't properly inheritable, and redirected command
> output got lost in the bit bucket.
>
There was a nice comment in that code about why we couldn't use
apr_file_dup. Anyway, I'm looking at the handle leaks right now.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: cvs commit: apr/threadproc/win32 proc.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 06:21 PM 7/2/2002, Brane wrote:
>Incidentally, I'm beginning to suspect that the root cause of the problem
>wasn't the patch itself, but the fact that apr_file_inherit_set is a noop.
Yup. That's brokenness.
>BTW, why are the apr_*_inherit set functions declared void, not apr_status_t?
Good question. I'd think that's broken too, since it certainly could fail
with a bad fd.
Bill
Re: cvs commit: apr/threadproc/win32 proc.c
Posted by Branko Čibej <br...@xbc.nu>.
Incidentally, I'm beginning to suspect that the root cause of the
problem wasn't the patch itself, but the fact that apr_file_inherit_set
is a noop.
BTW, why are the apr_*_inherit set functions declared void, not
apr_status_t?
Branko Čibej wrote:
> brane@apache.org wrote:
>
>> brane 2002/07/02 15:25:52
>>
>> Modified: threadproc/win32 proc.c
>> Log:
>> Reverting the 1.76 and 1.77 changes, because they didn't work.
>> The child handles weren't properly inheritable, and redirected command
>> output got lost in the bit bucket.
>>
>
> There was a nice comment in that code about why we couldn't use
> apr_file_dup. Anyway, I'm looking at the handle leaks right now.
>
>
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/