(see note on hup cleanup below) On May 5, 2004, at 2:51 AM, Sander Temme wrote:
Hi Mark,
Thanks for your observations.
On May 4, 2004, at 7:18 PM, mark wrote:
2)
Dettach is never needed. However, depending on desired results, it is usually desireable to perform a destroy when a HUP signal is sent, so that it gets created fresh by post_config
I've run into the strange errors under high load where newly forked children startup thinking they are attached to the inherited shm seg, but are in fact attached to some anonymous new segment. No error is produced, but obviously it's a catastrophic situation.
Yeah, that would be Bad. However, how does one hook into the SIGHUP handler? AFAIK, httpd has its own signal handlers that do stuff like restarts and graceful, and if I registered another handler, I would overrule the one that httpd sets. Or is there a provision for a chain of signal handlers?
You don't really need to worry about the SIGHUP handler, just tie a cleanup function to the pool used to create
it in post_config. This will be the process pool of the parent, and its cleanups get run after all the children exit on a restart. It works for me.
static apr_status_t
shm_cleanup_wrapper(void *unused) {
int rv;
if (shm_seg)
rv = apr_shm_destroy(shm_seg);
else
rv = APR_EGENERAL;
return rv;
}then in post_config:
apr_pool_cleanup_register(pool, NULL, shm_cleanup_wrapper, apr_pool_cleanup_null);
... where pool is the first parameter to post_config (and used to create shmseg);
I put the new version at <http://apache.org/~sctemme/mod_example_ipc.c> to save on e-mail bandwidth.
Thanks again,
S.
-- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
