How would an async I/O MPM handle a flush bucket? What I'm missing is that you may not always migrate the thread when doing an I/O because the non-I/O thread may still have stuff to write.
In Dean's descriptions of his ASH MPM (again, I may be missing something), he talked about how the thread desiring I/O would hand-off the request to the I/O thread and return to the idle state - the assumption is that the request is complete. But, making an I/O call doesn't mean that it is completed. Yet, that's the only clean way I can see how to handle this migration - because I don't see a way to resume the exact thread context in a clean way. (What I think we would need if we don't have a single thread per request is to supply a post I/O function that the I/O layer can indicate that a non-I/O thread should call when I/O is complete - pure event-based programming.) I guess I'm thinking of something like a proxy server application where we don't necessarily have all of the data up front - we may only have snippets of the data (because the origin server hasn't finished writing everything, but we have a partial response) - so write them out and flush as we get data. This seems valid under the 2.0 filter semantics. And, I'll argue that we must allow modules to call for a flush. -- justin
