httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: fix for hybrid server problems.
Date Mon, 03 May 1999 19:05:22 GMT
To be honest, I don't think we should preserve the current semantics of
HUP and USR1, MaxRequestsPerChild, .... Let's tie together a few ideas
and see how it fits.

You'll be surprised to hear me bring up an acceptor thread again... but
I have a reason for returning its existance:  to service static requests.
Each process will have one "event thread" which runs select on:

- a socket/pipe connected to the parent
- a socket/pipe used for the response queue
- all listening sockets/pipes
- all in-progress static responses (i.e. copy an fd or mmap out to the

Supporting all that should ammortize the value of the event thread.

The event thread communicates with worker threads through two queues --
the request queue, and the response queue.

Implement the request queue using whatever pthread synchronization
method seems appropriate.  The request queue can contain two different
data items -- a new connection, or a request_req of a finished static
response (with extra info needed for logging).

The response queue contains request_req's and the assorted fd/mmap info
needed to send the static response.  The response queue is implemented
using a pipe so that the event thread can use select() to find out when
it has events.  We can actually write "void *"s onto the pipe.

We only use the response queue for responses that send more than SO_SNDBUF
bytes of data.  No sense doing it for anything less, they won't have to
block, just write() directly and proceed to logging.

Add a new API phase -- "graceful shutdown".  This is invoked when
the parent asks the process to shutdown -- remember to a httpd child
there is no distinction between graceful shutdown or graceful restart.
When the graceful shutdown occurs, modules (and the core) should close
up any resource which might prevent another instance of the webserver
from starting... such as listening sockets.  The actual shutdown
won't occur until the last thread exits.  We can send events to the
event thread each time a thread exits... I think ... so the event
thread can take care of doing the final shutdown when the last thread

graceful restart and graceful shutdown are the two suggested forms
of restarting and shutting down the server.  They're the safe forms.
We can support a non-graceful shutdown... for this I don't care if we use
signals and destroy threads left and right, it's what the admin asked for.
(If you watch admins you'll notice many of them are lazy and use kill
-9 left and right, so this bad behaviour is pretty normal).

MaxRequestsPerChild (perthread, whatever) are best guesses.  We
don't guarantee that we'll hit them dead on.  When a worker thread
notices MaxRequestsPerChild has been hit, it sends an event to the
event thread, the event thread initiates a graceful shutdown of
the child process.

logging:  yeah, there is difficulty with log rotation if graceful
restart is the only restart available -- there's no way for an
external program to know that all children have finished writing
the rotated logs.  There's a few possibilities for solving this...


View raw message