httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: detecting stop|graceful|restart from httpd.conf
Date Tue, 28 Oct 2003 09:00:11 GMT
Glenn wrote:
> Ooops.  Reposted, changing:

[answering to the corrected context by Glenn]

 > I see a problem with both "prestart" and "graceful" indicating "first time"
 > because memory pools are cleared after preflight and after graceful.
 > Some modules might need to do some memory allocation during what you call
 > the "start" phase.  You would not want to do this during "prestart"
 > because it would be cleared.  But you would want it to run after
 > "graceful", because memory pools (except the main pool?) are cleared.
 > Doing it in child_init might be wasteful for forked MPMs, and a hassle to
 > do in child_init for threaded MPMs (e.g. having to keep tabs with SysV
 > conditionals PTHREAD_INIT_ONCE or atomics).  (Or should the plog log pool
 > be used here instead of the primary pool?)

These states will be set as soon as the config phase is finished. You have the 
open_logs and post_config phases to do the initialization. When these phases 
are run the state has already been set.

I didn't know graceful was rerunning preflight as well. I'm used to do a full 
stop and start. In which case it's possible that an additional state 
(pregraceful) is needed. Or I have a better idea, drop the pre- states 
completely. Instead indicate whether it's preflight/first_time or not. So 
these two flags give you all the information you need:

1. action: start|stop|graceful|restart
2. cycle:  first_time|second_time

> Prior to this thread, I had needed to keep this state myself and so I 
> reworked my previously posted macros into something which could just as
> easily be made a generic function.  It is included below, but not well
> tested.  If any of the comments below are incorrect, I'd be thrilled if
> someone would correct me.

what I dislike about the proposed macros is that each module needing this 
functionality will set a different key and read that different key, whereas 
the patch I have sent earlier provides this exact service for any consumer and 
does only one set operation besides simplifying the logic. Of course your set 
macro is more flexible as it can be called at any moment, whereas my patch 
suggested to run that same macro at the end of the config phase.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message