APR cross-platform signal semantics

[Nick Kew <ni...@webthing.com>]

Historically, different platforms have different signal semantics.

I need to set up a signal handler.  The primary targets are
Linux and Solaris, but I'd much prefer cross-platform.  And I'd
like it to be MPM-agnostic in httpd, though the prime target
is Worker.

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);
}


-- 
Nick Kew

Re: APR cross-platform signal semantics

[Nick Kew <ni...@webthing.com>]

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

Re: APR cross-platform signal semantics

[Garrett Rooney <ro...@electricjellyfish.net>]

On 2/4/06, Nick Kew <ni...@webthing.com> wrote:
> Historically, different platforms have different signal semantics.
>
> I need to set up a signal handler.  The primary targets are
> Linux and Solaris, but I'd much prefer cross-platform.  And I'd
> like it to be MPM-agnostic in httpd, though the prime target
> is Worker.
>
> 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...

-garrett