Re: $r->child_terminate possible suggestion

>>>>> So may be there is a need to expose it via a proper ap_ api?
>>>>>
>>>> Oh, it's definitely better if we can get an ap_ api for this, and I
>>>> am plannnig on either writing on or at least pigning
>>>> the folks at httpd-dev about it. I was merely proposing a suggestion
>>>> that might just fit our needs for now, while we
>>>> are looking for the best solution.
>>>
>>> using a api call vs. signals is not the same thing, so I'm not sure
>>> it's a good temporary solution in case we are going to have a proper
>>> api call.
>>
>>
>>
>> In my opinon, the here are the various solutions in order of preference
>> 1. Call an ap_* function
>> 2. Send a SIGTERM
>> 3. Call exit() directly
>>
>> And most likely, 2 & 3 only make sense for non-threaded MPMs
> 
> 
> Right.
> 
> OK, so anybody wants to start this thread to httpd-dev before we decide
> how to handle it with mod_perl?

I would strongly suggest that we come up with a patch before asking
httpd-dev, as (especially these days) everyone is busy and there are few
free tuits available for the kind of in-depth discussion you are probably
seeking.

I did start looking at this several times, and it seems as though
de-localizing the requests_this_child variable (or whatever it is) would
universally suit our needs.  if that is true, I think our needs would be met
if there were an ap_ api that would allow this value to be set.  the only
issue here is that every MPM would need to support it, but that may not be
that big of a deal since there are other functions that every MPM is
expected to provide (IIRC, that is).  or maybe we could register it as an
optional function or something.

anyway, if indeed the requests_this_child approach would work for all MPMs I
would suggest that we (well, somebody :) come up with a patch that ports
prefork, worker, and winnt over to the new API and present it in its
entirety to new-httpd.  this way there would be a concrete patch to
integrate into 2.1 (and thus vote on for 2.0) if discussion is relatively
sparse.

if the requests_this_child approach isn't sufficient, forget this email :)

--Geoff