httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <>
Subject Re: win32: reason for inactive service taking 60s to shutdown
Date Fri, 02 Jan 1998 12:08:08 GMT
On Tue, 30 Dec 1997, Marc Slemko wrote:
> I like the windows manual:
>   Note SIGINT is not supported for any Win32 application including Windows
>   NT and Windows 95. When a CTRL+C interrupt occurs, Win32 operating systems
>   generate a new thread to specifically handle that interrupt. This can
>   cause a single-thread application such as UNIX, to become multithreaded,
>   resulting in unexpected behavior. 
> I wasn't aware UNIX was a single-thread application.

Welcome to Microsoft speak. Next you'll be suggesting that all the great
new NT5 features - like disk quotas, cron jobs, scripting, mountable
media, backups to non-tape devices, per-user home directories, remote
graphical access - have already been invented in other OSes. Surely not?

> Anyway, about the reason why Apache takes 60 seconds to terminate
> as a service if no requests come in.  The problem is that the child
> blocks in select() and doesn't get around to the event until the
> next time around the loop.

Yep, this is a problem. In my big patch of Win32 fixes, I changed this to
a one-second wait:

| - worker_main() now will not exit until all the connections in its
|   listen() queue are dealt with (previous it would "count_down" a
|   few requests, then die, which would loose the connections in
|   this process'es listen() queue). This now makes graceful restarts not
|   lose connections. Once worker_main() has been told to exit it
|   frees the mutex to allow another worker_main() to get into a listen()
|   [however it seems Win32 directs incoming requests to the first process
|   annoyingly]. To give the old worker_main() a chance to exit,
|   only sleep for 1 second in the select. Also catch problems if the
|   select() returns immediately with an error (previously this would
|   cause a busy loop forever).

In the current code, the parent process also has a loop containing a two
second delay. With my patch this becomes an infinite delay.

> I couldn't find anything in the Windows API to easily let us 
> deliver something to the app that will abort the select() early,
> nor could I figure out anything that will let us wait for either
> at the same time; the winsock functions are seperete from the
> WaitForSingleObject type calls.  

We can do this with an event. My patch creates an event called
"apache-signal" which is used to wake the parent up and get it to do
something. It can be used for both graceful restarts and (graceful)

You should be able to do something similar with WaitForMultipleObject
calls using both sockets and events, but I couldn't actually make this
work (waiting on a socket for a connect event, that is). Plus I think it
is nicer if the parent process is the one which gets notification of
apache "signals" (if the threads get the notification, they have to tell
the parent anyway, since otherwise the parent will happily recreate the
child process after it kills itself -- not very useful for doing a

I really would like to see my Win32 MT patch incorporated into the code. 
It fixes a lot of problems like these (although it isn't perfect, it is a
lot better than the current code. In my opinion anyway). 


View raw message