At 10:01 AM 3/21/2003, Joe Orton wrote: >On Fri, Mar 21, 2003 at 10:49:08AM -0500, Jeff Trawick wrote: >> apr_file_io.h says >> >> /** >> * Unset a file from being inherited by child processes. >> */ >> >> should it instead say something like this? >> >> /** >> * Unset a file from being inherited by subprograms >> */ >> >> where subprogram is a child process running another executable, as >> contrasted with a child process running the same executable (i.e., >> fork() but no exec()) > >Whilst the latter is true on Unix I'm getting the impression from what >Will is saying that the former is true on Win32. (The comment about >child_cleanups in apr_pools.h is equally confusing.)
Understand that fork() doesn't exist on win32 (the Perl pseudo-support notwithstanding.) So Unix has fork()->exec(), or simply fork(). Whereas Win32 has only exec(). Any 'child process' logic as an Apache MPM understands that idea doesn't even exist on Win32. We must implement our own communications layer to identify the handles that are inherited by the children. Windows really works more like the FD_CLOEXEC model for Unix file handles. The pool 'child cleanup' on Win32 is truly a noop. Bill
