httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: Async I/O question?
Date Wed, 05 Dec 2001 21:22:59 GMT
isn't this VERY similiar to what SGI's state machine thingy was
going to do ?
On Wed, 2001-12-05 at 13:10, Ryan Bloom wrote:
> 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				rbb@apache.org
> Covalent Technologies			rbb@covalent.net
> --------------------------------------------------------------
-- 
Ian Holsman          IanH@cnet.com
Performance Measurement & Analysis
CNET Networks   -   (415) 344-2608


Mime
View raw message