Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Dev

APR cross-platform signal semantics

 

 

Apache dev RSS feed   Index | Next | Previous | View Threaded


nick at webthing

Feb 4, 2006, 9:24 AM

Post #1 of 3 (1341 views)
Permalink
APR cross-platform signal semantics

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


rooneg at electricjellyfish

Feb 4, 2006, 10:12 PM

Post #2 of 3 (1202 views)
Permalink
Re: APR cross-platform signal semantics [In reply to]

On 2/4/06, Nick Kew <nick[at]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


nick at webthing

Feb 5, 2006, 8:09 AM

Post #3 of 3 (1199 views)
Permalink
Re: APR cross-platform signal semantics [In reply to]

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

Apache dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.