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 [EMAIL PROTECTED]
> Covalent Technologies [EMAIL PROTECTED]
> --------------------------------------------------------------
--
Ian Holsman [EMAIL PROTECTED]
Performance Measurement & Analysis
CNET Networks - (415) 344-2608
