httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: Async I/O question?
Date Wed, 05 Dec 2001 21:10:42 GMT
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:
		hand-off request to worker
	end of loop

worker thread:
		receive request
		wait for data from I/O thread
		process request
			Generate data			
			hand-off data to I/O thread
		End of Loop
	End of Loop

I/O thread:
		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


> 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
Covalent Technologies

View raw message