> > > On Monday 12 November 2001 07:22 pm, William A. Rowe, Jr. wrote: > > > From: "Ryan Bloom" <[EMAIL PROTECTED]> > > > Sent: Monday, November 12, 2001 8:55 PM > > > > > > > The problem that remains is Windows. Windows starts the server, and > > > > creates one thread for each socket that is configured. That thread sits > > > > in accept, and passes the accepted socket to worker threads. This seems > > > > like a waste of resources, but I will accept that the Windows experts > > > > know what they are doing. My problem is that it doesn't really fit the > > > > model above. I guess that Windows could work by using the first hook > > > > above, and then looping through the apr_pollfd_t, creating threads that > > > > call the third hook above. > > > > > > Uh... no, that's AcceptEx, and it has entirely different mechanics. There > > > will always be data to process when a winsock has accept-ex-ed a socket > > > (thus the different API.) Ergo, no thread is woken until it has a job to > > > do. > > > > I have a stupid question. I have been looking at the Windows code, and I > > can't see where the data that is read by AcceptEx ever gets to the processing > > thread. Does that data ever get to the thread doing the work? If so, how???? > > > > See PostQueuedCompletionStatus() and GetQueuedCompletionStatus(). > > The worker thread pool blocks on GetQueuedCompletionStatus() in >winnt_get_connection(). > winnt_accept() accepts connections and calls PostQueuedCompletionSTatus() to wake up >one > of the workers blocked on GetQueuedCompletionStatus(). > > Notice the queue of 'completion contexts' that flow between the two calls. And the > ThreadDispatchIOCP is a Windows "Completion Port" a kernel resident FIFO queue of >sorts. > > Give me a call tomorrow and I'll walk you through it in detail if you like. > > Bill >
BTW, the NT code patch for accepting/dispatching connections is different from the Win9* path. 9* does not support CompletionPorts. Bill
