httpd-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] resend: fix fd leaks
Date Tue, 18 Mar 2003 13:54:00 GMT
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



Mime
View raw message