httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject Re: [PATCH 5/6] hard restart on Linux #38737
Date Mon, 08 May 2006 10:19:59 GMT
On 5/7/06, Nick Kew <nick@webthing.com> wrote:
> On Thursday 04 May 2006 19:16, Chris Darroch wrote:
>
> > +#ifdef HAVE_PTHREAD_KILL
> > +    unblock_signal(WORKER_SIGNAL);
> > +    apr_signal(WORKER_SIGNAL, dummy_signal_handler);
> > +#endif
> > +
>
> OK, unblock a signal.  This happens after child_init, but presumably
> won't interfere with existing modules 'cos a module that attaches a
> handler for that in a child_init wouldn't have worked before, either.

AP_SIG_GRACEFUL is our signal to play with.  Modules can't change how
that is delivered and expect the server to work reliably.

>
> Question: what other side-effects might this have?

unpredictable if somebody/something sends AP_SIG_GRACEFUL to the child
process; it will land on random worker thread

(it might be nice for debugging if you could make processes gracefully
exit by sending them the signal; but we don't have such code so I
don't see how using it for this intra-child communication will break
anything)

APR generally eats signals.  The app can set a flag in their signal
handler and check later, but APR won't return EINTR except from a
couple of functions (poll and accept perhaps?).  So there is the
possibility that the signal won't prod the worker thread from wherever
it is  But that's no worse than today, and we still close the socket.

>                                                                                Anyone
recollect
> why signals are commonly blocked in the child processes?

We want the main thread in the child process to see any signals and
the worker and listener threads to be oblivious to signals.

If a third-party module has its own thread and uses a signal for its
own purpose, it unblocks that signal on its thread and we're
oblivious.

Mime
View raw message