On Wednesday 05 December 2001 12:27 pm, Justin Erenkrantz wrote:
two things.
1) In a full Async model, you would need to be able to recover
the threads context. That isn't possible without major
re-working of Apache, and that would be a good reason to move
on to Apache 3.0.
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.
accept thread:
Loop
select
accept
hand-off request to worker
end of loop
worker thread:
Loop
receive request
wait for data from I/O thread
process request
Loop
Generate data
hand-off data to I/O thread
End of Loop
End of Loop
I/O thread:
Loop
if somebody's waiting for data
Read from network
hand-off data to worker
end if
if data to write
receive data from worker
write to network
end if
End of Loop
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.
The big trade-off with this async model is the sheer scalability. If the
threads aren't waiting to actually read and write data, they are just
processing requests, and for a small request, this can be done insanely
quickly.
Ryan
> 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
--
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
