>>>>> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
