httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <p...@eu.c2.net>
Subject RE: NT to do list
Date Sat, 10 Jan 1998 18:01:13 GMT
On Fri, 9 Jan 1998, David D'Antonio wrote:
> >   Replacement for signal handling.  Paul's recent
> >   changes might cover this, when I glanced at the original
> >   they seemed to provide an named event that could be zapped 
> >   to inject the equivalent of signal, but not a tool to
> >   do the zapping.  - Doc to explain mechinism required.

Yep, there is a named event "apache-signal", but you also need to set an
variable (to indicate if you want a restart or a shutdown) -- so other
processes cannot just raise the event. "apache-signal" is only supposed to
be an internal event, used to wakeup the parent process which will be
asleep in an infinite wait. 

At some point in the future it would be nice to have a way of calling into
the running Apache parent process -- say via DCOM -- and that call would
initiate the restart or shutdown (by calling start_restart or
start_shutdown). If DCOM is too complex (and I think it is, at the moment) 
there may be other ways of getting into into a running process -- perhaps
create a separate thread and get that thread to have a message loop,
somehow. Is that possible? 

Anyway, probably a better way is to create a new event for each type of
signal -- say "apache-restart", "apache-stop" -- then create a new thread
in the parent process which waits on all these external signals. When one
gets raised, it called start_shutdown or start_restart as necessary. 

Another way could be to have a named pipe and have a parent process thread
read it for control messages. Rather like INNd's controller. That would be
neat and extensible to Unix, but would only work on NT since 95 doesn't
have named pipes.

> MS certainly believes that TransmitFile is the way to go (unless
> ISAPI filters need access to the outgoing stream)

Well, Apache doesn't currently work with ISAPI filters. I think if we go
to TransmitFile and friends we really need to completely re-organise the
way that data is transmitted to make it into a fully overlappedIO-aware
application. I.e. reduce the number of threads and get each to work
asynchronously on multiple overlapped IOs -- like MS tells you to do for
fast IO. Shame they had to make async IO so different from the familar
Unix IO. 

//pcs


Mime
View raw message