Remove some deprecated comments.

}

/**********************************************************************

 * Multithreaded implementation

 * Child Process Notes

 *

 * This code is fairly specific to Win32.

 * The child process in the mpm_winnt consists of one 'master' thread

 * and one or more worker threads.  The master thread is responsible for

 * creating the worker threads, performing server maintenance, and for 

 * listening for the parent process to signal the child process to 

 * shutdown. The master thread runs and sleeps in child_main(). The worker

 * threads run in worker_main().

 *

 * The model used to handle requests is a set of threads. One "main"

 * thread listens for new requests. When something becomes

 * available, it does a select and places the newly available socket

 * onto a list of "jobs" (add_job()). Then any one of a fixed number

 * of "worker" threads takes the top job off the job list with

 * remove_job() and handles that connection to completion. After

 * the connection has finished the thread is free to take another

 * job from the job list.

 * mpm_winnt implements two seperate models for binding connections to

 * threads: one specific to Windows 95/98 and another specific to Windows 

 * NT/2000. 

 *

 * In the code, the "main" thread is running within the child_main()

 * function. The first thing this function does is create the

 * worker threads, which operate in the child_sub_main() function. The

 * main thread then goes into a loop within child_main() where they

 * do a select() on the listening sockets. The select times out once

 * per second so that the thread can check for an "exit" signal

 * from the parent process (see below). If this signal is set, the 

 * thread can exit, but only after it has accepted all incoming

 * connections already in the listen queue (since Win32 appears

 * to through away listened but unaccepted connections when a 

 * process dies).

 * On Windows 95/98 a single thread (the accept thread, created by the 

 * master thread in child_main()) "accepts" connections off the listining 

 * socket. When a connection is accepted, the accepted socket is placed 

 * onto a queue of "jobs" (add_job()). The worker threads consume from 

 * the top of this job queue with remove_job() and handle requests coming 

 * in on that connection until the connection is taken down.

 *

 * Because the main and worker threads exist within a single process

 * they are vulnerable to crashes or memory leaks (crashes can also

 * be caused within modules, of course). There also needs to be a 

 * mechanism to perform restarts and shutdowns. This is done by

 * creating the main & worker threads within a subprocess. A

 * main process (the "parent process") creates one (or more) 

 * processes to do the work, then the parent sits around waiting

 * for the working process to die, in which case it starts a new

 * one. The parent process also handles restarts (by creating

 * a new working process then signalling the previous working process 

 * exit ) and shutdowns (by signalling the working process to exit).

 * The parent process operates within the master_main() function. This

 * process also handles requests from the service manager (NT only).

 *

 * Signalling between the parent and working process uses a Win32

 * event. Each child has a unique name for the event, which is

 * passed to it with the -Z argument when the child is spawned. The

 * parent sets (signals) this event to tell the child to die.

 * At present all children do a graceful die - they finish all

 * current jobs _and_ empty the listen queue before they exit.

 * A non-graceful die would need a second event. The -Z argument in

 * the child is also used to create the shutdown and restart events,

 * since the prefix (apPID) contains the parent process PID.

 *

 * The code below starts with functions at the lowest level -

 * worker threads, and works up to the top level - the main()

 * function of the parent process.

 *

 * The scoreboard (in process memory) contains details of the worker

 * threads (within the active working process). There is no shared

 * "scoreboard" between processes, since only one is ever active

 * at once (or at most, two, when one has been told to shutdown but

 * is processes outstanding requests, and a new one has been started).

 * This is controlled by a "start_mutex" which ensures only one working

 * process is active at once.

 * Windows NT/2000 uses an advanced Winsock2 APIs (AcceptEx() and

 * completion ports) to handle dispatching connections to worker 

 * threads. add_job/remove_job are not used by the NT/2000 specific

 * code path. Instead, each worker thread is responsible for calling

 * AcceptEx().

 **********************************************************************/

    CloseHandle(exit_event);

}

/*

 * Spawn a child Apache process. The child process has the command line arguments from

 * argc and argv[], plus a -Z argument giving the name of an event. The child should

 * open and poll or wait on this event. When it is signalled, the child should die.

 * prefix is a prefix string for the event name.

 * 

 * The child_num argument on entry contains a serial number for this child (used to create

 * a unique event name). On exit, this number will have been incremented by one, ready

 * for the next call. 

 *

 * On exit, the value pointed to be *ev will contain the event created

 * to signal the new child process.

 *

 * The return value is the handle to the child process if successful, else -1. If -1 is

 * returned the error will already have been logged by ap_log_error().

 */

/**********************************************************************

 * master_main - this is the parent (main) process. We create a

 * child process to do the work, then sit around waiting for either