At 11:02 AM 1/26/2003, Thom May wrote:
>* G�nter Knauf ([EMAIL PROTECTED]) wrote :
>> > * Guenter Knauf ([EMAIL PROTECTED]) wrote :
>> >> Hi,
>> >> I can see that mod_log_config, mod_rewrite and mod_file_cache have it in;
>> >> but where in the source tree is APR_INHERIT as set by
>> >> apr_file_inherit_set() actually handled?
>> >> A grep of the source tree does not find any application of this flag.
>> >> Is it really implemented yet, or just a dummy?
>> >>
>> > see apr_arch_inherit.h in include/arch/*/
>> Thats a useless answer. I want to see a .c that implements whats defined in a .h.
>
>Both Will Rowe and I have replied to you, on seperate threads with *exactly
>the same answer*. Have you looked in the header file?
Actually, the confusion may stem from the fact of looking at /arch/win32/
which are noops ... Only Unix toggles the 'close handle on fork' option
by togging the cleanup. We should probably also implement the recent
cleanups patch to Apache 1.3 in a similar manner right here at this point
in the macros.
... because Win32 can create handles for inheritence, but we have no method
of actually *sending* the handles to the client, we've forgone that implementation
so far. It does no good to have a dozen log handles when we can't reconnect
them in the child process; they are just wasted resources.
I've been trying to come up with a schema for sending such handles to the
child process. Either 1) we have to register them such that the child process
can recover the handles and their purposes, or 2) we set up a mechanism for
giving the child an unlimited handle to the parent process, and the parent's
own handles. For security, once we are done duplicating any parent handles
we want to use, we close the handle to the parent process (which we can
never regain again.)
It's not exactly a coin toss, the design paradigms are very different. Once
my head is above water (post 2.0.45) I'd be happy to implement both of these
flavors (store meanings and let the child inherit the handles, v.s. pass parent
handles for the child to duplicate at it's discresion) and we can compare the
benefits of each.
One downside to the inherited handles, when we don't fork, is the (modestly)
high probability of extra handle leaks for no good cause. The downside to
either solution (and the real meat of the issue) is; which model causes
module authors the least extra pain to support non-forked platforms?
We shall see.
> From apr_arch_inherit.h in include/arch/unix/
>
>#define APR_IMPLEMENT_INHERIT_SET(name, flag, pool, cleanup) \
>apr_status_t apr_##name##_inherit_set(apr_##name##_t *the##name) \
>{ \
> if (!(the##name->flag & APR_INHERIT)) { \
> the##name->flag |= APR_INHERIT; \
> apr_pool_child_cleanup_set(the##name->pool, \
> (void *)the##name, \
> cleanup, apr_pool_cleanup_null); \
> } \
> return APR_SUCCESS; \
>}
