httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <man...@io.com>
Subject Re: fix for hybrid server problems.
Date Fri, 30 Apr 1999 07:09:48 GMT
On Mon, Apr 26, 1999 at 04:22:51PM -0400, Ryan Bloom wrote:
> All threads accept SIGWINCH(graceful) and SIGHUP(non-graceful).  When a
> thread gets either signal, it sets it's spot in the scoreboard, masks that
> signal to SIG_IGN, checks to see if there are any more active threads, and
> if so, re-sends the signal to it's own process.

We found some problems with this approach, one being that we can't do
per-thread signal masking without a pthread call, and we can't make
pthreads calls from signal handlers (grumble).

However, we've heard (and tested on Linux) that signal handlers run
uninterrupted as far as other threads in a process are concerned. If
true, at least for server shutdown, we could simply put the
clean_child_exit() inside a signal handler. But, the pools use
mutexes, and you can't make mutex calls inside signal handlers. So,
this would only be possible if we could pass arguments in to the pool
routines not to use mutexes. This is ugly, though.

The fundamental problem is that shutdown has the semantics of killing
the server very quickly. Those semantics mean we have to kill threads
in the middle of requests. If we didn't have third-party modules, the
worker threads could regularly check a shutdown flag. But we do have
third-party modules, and they could put long delays between flag
checks.  So, it seems we *have* to use some form of asynchronous
cancellation: either just exit()ing while our threads are running, or
Unix signals, or pthread_cancel(). And Unix signals just cause no end
of grief when mixed with threads.

Personally, I'm starting to lean towards pthread_cancel in deferred
mode to kill our worker threads when we get SIGTERM. Asynchronous
cancellation is evil, but in the hybrid server right now, we're just
exit()ing while our other threads are running, so we already have an
effective form of asynch cancellation. Of course, the problem is that
we could run into cancellation-unsafe third-party libraries. I think
that a module written to interface the third-party library could block
cancellations if there that's a concern, but it's only half an answer.

Thoughts?

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"Yes, I'm Linus, and I'm your God" -- Linus Torvalds, Linux Expo '98

Mime
View raw message