Joe Orton wrote: > On Fri, Sep 07, 2007 at 02:59:10PM -0500, William Rowe wrote: >> FYI - this bug appears to be the root of several modules no longer >> behaving as expected on Win32 platforms. >> >> It takes me back to a question I raised on apr quite a while ago, >> what does *unix* do with an unset child_in/child_out/child_err >> procattr member? >> >> If it is unset, does the child inherit the processes' std handle? >> AIUI - with our apr implementation, it does. > > That's what the Unix implementation does; fds 0-2 will be untouched so > will remain exactly as in the parent. (Of course, none of this stuff is > documented as an API constraint.)
Right, very true. It's implicit, and a lurking surprise. So (of course) is the reliance on invalid handles, null handles and so on. We've been bitten by MS's own changes between NT and XP as it evolved to go from some handle to NULL handle in the service context. Since it -seems- we can establish a contract, and we didn't have one before, this is something worth fixing if we can do so -without breaking abi-. I'm going to suggest an APR_NO_FILE flag, similar to APR_NO_PIPE, but with the added purpose of 'closing' (not inheriting to the running child) that undesired FD on any platform. I believe the patch will allow mod_fcgid maintainers to modify their module to use a documented behavior instead of an 'undocumented feature'. For 95% of the world, it should be a noop of a change. Bill
