httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: Apache calls initialize module twice
Date Thu, 13 Nov 2003 19:43:16 GMT
William A. Rowe, Jr. wrote:
> At 02:18 PM 11/10/2003, you wrote:
> 
>>Bill Stoddard wrote:
>>[...]
>>
>>>>   Any ideas how to avoid the second call to initalize_module when I run as
a service ?
>>
>>
>>>You can't avoid the second call but there are ways to gracefully handle it. Here
is a snip of code from a module I developed a while back:
>>
>>[...]
>>and I posted a patch which provides a generic API to do that. Since everybody is replicating
this code. And the thread has died w/o resolution. For some reason http://marc.theaimsgroup.com
doesn't have my original post, but only the rest of the (unfinished) thread.
> 
> 
> Stas,
> 
>   Since the work arounds (such as Bill suggested) are required for 1.3 and 2.0
> compatiblity already, it seems we should focus on 2.1 and solve this for good.

as far putting a solution in 2.0, what is it our concern if a module wants to 
support only Apache >= 2.0.50?  we may have our own modules that need such an 
API enhancement

>   We have a new facility, ap_mpm_query, which would be perfect for answering
> nuggets of wisdom such as;
> 
>   * Running as a win32 service?  Or detached console daemon?
>   * A parent process?  (Pre-fork or never forking (e.g. win32?)
>   * Pre-startup config testing?
>   * Server generation?  (This answers the 2nd, 3rd, 4th startup pass question)

a check for is-terminating would be nice too...  there's a nice mod_cgid 
restart patch in 2.1-dev that needs a way to query whether the other child 
checker got APR_OC_REASON_DEATH because the other child died on its own or 
because it died because the server is terminating...  right now the logic uses 
ap_graceful_stop_signalled(), which is a dummy function with prefork... with 
worker, ap_graceful_stop_signalled() works well enough for the mod_cgid patch, 
but it doesn't distiguish between graceful and ungraceful termination

If we add AP_MPMQ_QUERY_STATE request that returns one of 
{AP_MPMQ_STATE_INITIALIZED, AP_MPMQ_STATE_INITIALIZING, 
AP_MPMQ_STATE_GRACEFUL_STOP, AP_MPMQ_STATE_HARD_STOP}, modules ought to be able 
to get some type of clue on the big picture, though that doesn't help with 
which pass of the pre/post-config hook it is.

ap_mpm_query(), implemented by each MPM, would need some help from core to 
determine which pass of the pre/post-config hook it is, since that is out of 
the MPM's domain.

I must admit I don't understand the original initialize-module question and how 
it relates to whether MPM is run with -X mode.  Any clues?  I can see plain as 
day the pre-config/post-config issue in server/main.c:main().  Without that 
understanding, I'm not sure what sort of info sharing is needed between core 
and the MPM to allow module to know whether or not this is the last time a 
certain hook will be called during [re-]initialization.


Mime
View raw message