On Wed, Dec 05, 2001 at 01:10:42PM -0800, Ryan Bloom wrote: > 2) In a partial Async model, like what Dean is suggesting, the > I/O thread needs to be able to accept multiple chunks of data > to be written to the client. This would allow you to handle a flush > bucket, and the processing thread wouldn't stop processing the > request, it juts wouldn't wait to continue processing if the data > couldn't be written immediately. The point is to get the processing > threads done with the request ASAP, so that they can handle the > next request. The I/O for the threads can wait an extra 1/2 second > or two. > > Think of it as three threads all working together.
<light bulb goes on> > Now, this can be improved even more by moving to a four > thread model, where one thread is dedicated to reading from > the network, and one is dedicated to writing to the network. Thanks for the clarification. It helps tremendously. So, we aren't talking about a pure async-model - just where we attempt to hand-off. And, moving to a four thread model may be hindered by the specific OS - like /dev/poll can indicate reading and writing on the same socket. Would we want two threads sharing ownership of the socket? Perhaps. However, something like SSL would complicate things (think renegotiations). Now, some questions: 1) Any transient buckets will have to be setaside in this MPM. Is this a concern? It seems that you also can't reuse the same memory space within the output loop. Once I pass it down the chain, I must say good-bye to any memory or data pointed within the bucket. (We couldn't even reuse heap data.) Is this even a change from current semantics? 2) We could implement this solely by manipulating the socket hooks you added, right? Would there be any change external to the MPM? (I guess we wouldn't know until we tried perhaps...) 3) In the read case, the I/O is directed to a specific worker thread, right? So, a worker thread makes a request for some amount of I/O and it is delivered to that same thread (so we can still use thread-local storage)? The wait for data from I/O thread in worker thread will be synchronous. 4) What happens when all of the IO threads are full (and their ensuing buffers are full too)? Do we just force the worker to wait? In fact, I'd imagine this would be a common case. The worker threads should be fairly fast - the IO thread would be the slow ones. Thanks again. I now see the big picture... I need to study for my exams now... -- justin
