httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: APR cross-platform signal semantics
Date Sun, 05 Feb 2006 16:09:58 GMT
On Sunday 05 February 2006 06:12, Garrett Rooney wrote:

> > Is the following correct and complete for APR signals
> > to function across platforms?
> >
> > static void my_handler(int signum) {
> >   apr_signal_block(signum) ;
> >   /* do things */
> >   apr_signal_unblock(signum) ;
> > }
> >
> > static void my_child_init(args) {
> >   apr_signal(MY_SIGNAL, my_handler);
> > }
>
> That seems reasonable to me, although I suspect the behavior with
> regard to how signals interact with threads will vary from system to
> system, although apr_setup_signal_thread seems relevant to that part
> of the problem...

So it would seem.  The worker and event MPMs both use that, and block
signals set up in a child_init hook.  Looks like I can't do this in a 
module:-(

The underlying problem is to implement graceful-stop of a single child
process.  It seems I can't do that using the pod, because I can't select
a child process, so I'm trying to signal.  The idea is;

* graceful signal -->  close listeners
   ... delay ...
* TERM signal --> destroy pchild, apr_terminate, exit
   ... delay ...
* KILL signal as a last resort

I thought I had it wrapped up, but the IPC for the above eludes me.
Communicating by HTTP has the same problem as the pod: I don't
get to choose which child gets signalled, and it also has MPM issues.

Any alternative suggestions?  Preferably without touching the core
code and (especially) the individual MPMs?  Or do I need to do something
drastic like fork a new "supervised" MPM from worker?

-- 
Nick Kew

Mime
View raw message