Tom Donovan wrote:
William A. Rowe, Jr. wrote:
Steffen wrote:
mod_perl on Windows 2.2.7
Using http://theoryx5.uwinnipeg.ca/ppms/ with ActivePerl 5.8.8.822
FAILS
I posted an updated patch to bug 43534 for 2.2.7 rc.
Thanks Tom, saw it, reviewing it now.
Currently the parent creates a handle to "NUL" which gets passed to the
child and dup'd to stdin after the parent-pipe is closed. This works
fine - but it is only done when Apache is started as a service.
Since a parent's console can't be inherited by a child which is started
as a detached process - this "NUL" stdout is needed for command-line
startups too.
Gotcha, made sense.
* Apache 2.2.7 started as single process from command-line
httpd.exe -X
WORKS OK
Now that's a little nutty. Would expect -X case to mirror the
other command line case. Good clues.
In single-process (-X) there is no child process creation, no handle
inheritance (or non-inheritance), and the original stdout is a valid
console handle. mod_perl is happy with this.
One puzzling thing when trying to follow inheritance. Since change
570303 on the APR 1.2 branch (change 569882 on APR trunk), the functions
apr_file_inherit_set() and apr_file_inherit_unset() are commented out
and become no-ops for WINNT and higher (i.e. when IF_WIN_OS_IS_UNICODE
is true).
See apr/include/arch/win32/apr_arch_inherit.h near lines 32 and 55
These function are used a lot in threadproc/win32/proc.c - and also used
in Apache's mod_file_cache & mod_mem_cache.
I'm not sure if this change is really intentional or a bug.
Extremely intentional. HTTPD is a multithreaded app. Multiple processes
are in the process of being spawned at the same time for different purposes.
It's especially critical that the usual 'inherited' pipe or file handle of
one thread is not inherited on another thread, this was the cause of the
pipe leakage.
Only three handles should be inherited 'by default' without extra effort.
STDIN, STDOUT, and STDERR. And 'flip' them into an non-inherited state
when a non-default handle is desired.
None of this works on win9x, we can't simply flip this bit. That's why the
arch_inherit still does the 'old thing' with 9x builds, we need to let that
pipe leakage continue if someone actually uses this junk.
So where on earth are files inherited? The answer happens to be the bane
of our existence, _dup2(fd, 2); There are a host of side-effects in letting
MSVCR into our handles support, one of them is that the stdio dup'ed handles
are always set inheritable. It's worth noting if you ever try to implement
anything similar.
The reason everything works is that even in file_cache and mem_cache, the
child is repeating all the steps the parent did. So inheritance is not
really used anyways. There's no copy-on-write shared heap through fork()
as there is on Unix. It's possible to implement; and it breaks many win32
loadable dll libraries (principal of unexpected consequences).
We'll need to modify the whole API of httpd before we can start passing
other useful things down to the child process. Using inheritance turns
out to be kludgy in a multithreaded environment; explicitly copying the
additional handles into the child process space turns out to be cleaner.
Back to your patch; as I mentioned I'm reviewing and will commit ASAP.
Bill
