At 03:25 AM 3/18/2003, Joe Orton wrote: >On Mon, Mar 17, 2003 at 11:56:11PM -0600, William Rowe wrote: >> We don't have the mechanics in place so right now this is a beneficial >> noop on Win32. However, we should be passing those handles on to >> all child processes. That won't happen today, but will occur in the very >> near future. The XXX comments will remind me what I need to wiggle >> to make this work. > >I don't really understand this... the file_inherit interface concerns >whether files are inherited by exec()d processes, not any "child >processes", on Unix. Is there some mismatch in the Win32 >implementation? Why should httpd need this APR call specifically for >Win32?
Unix fork()s children. Win32 must exec() (CreateProcess) them, and we need a mechanism for storing those "must be shared" objects between the parent and worker processes. We need a relatively trivial way to distribute those fds/handles from parent to child on !APR_HAVE_FORK platforms. I don't have the "one right answer" to this, but it must be trivial for module authors to use. One thought is a shared userdata table of apr_file_t's that can be stashed in apr_process_t. If that table has entries - it could become the MPM's responsibility to propogate that table from parent to child process. Or the mechanism could 'act' more like Unix domain sockets, with an accessor that moves these handles from parent to child. Anyway, 10% of the effort will be on the module author when they want to share items like log file handles, etc, 10% by existing APR code, and the 80% of the heavy lifting will be done by the MPMs of those processes that need it. Bill
