apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: [PATCH] apr/threadproc/win32/proc.c:apr_proc_create()
Date Fri, 19 Jul 2002 06:07:37 GMT
At 08:15 PM 7/18/2002, Rob Saccoccio wrote:
> > And what was the side-effect of NULL handles to stdout/stderr
> > that you observed?  That's what I've been trying to determine.
>
>Oh, sorry.  There was no apparent side effect.  The resulting process had
>stdout/stderr HANDLEs of 0 as one would expect.
>
>If they're not set to INVALID_HANDLE_VALUE then you've no way to know that
>they're not real.

Actually, you better expect to look for NULL.

If you are writing service applications, the handles are ALL NULL when
your process starts on Win2K/WinXP.  So there really was no effective
difference, since [at least service] apps already have this issue.

But since that doesn't conflict badly with INVALID_HANDLE_VALUE,
I'm happy to let the patch stay in.  Thank you for submitting it, and
next time around, try to clue us in upfront the observed v.s. expected
behavior problem you had observed was :-)

>While I've got you on the line, why do you do the dup() (in
>apr_procattr_child_in_set()) and close() (in apr_proc_create())?

To toggle the INHERITED attribute of the files.  I'm not suggesting
it's toggled correctly [no time to look at the moment] but recognize
that we are trying to create handles as non-inherited by default, but
need to promote them to INHERITED flavors to pass between other
processes.

Bill


Mime
View raw message