Yep, my thoughts exactly. I am really interested in working on an Async MPM (in fact, I have a windows MPM that does async writes. I have done one that does async reads. Now just need to combine the two :-)
The big change that needs to happen is to enable setting a network layer nonblocking attribute at the top of a filter stack, at the handler. The handler must make the decision whether it wants to do async/non-blocking i/o or not. Probably also need to establish the completion context at the top of the filter stack as well (the structure that enables you to regain context after the pending i/o completes) Oh, and we need to handle the fact that async i/o and non-blocking i/o are really different things. Windows uses async i/o rather than non-blocking i/o. That is, a windows network call that doesn't complete immediately is taken over by the kernel and a kernel thread will do the i/o on behalf of the application thread. When the i/o is complete, the completionport associated with the socket is posted to wake up an application thread to complete the work. The application must be damn careful not to muck with the storage passed to the kernel on an async i/o. /dev/poll, kqueue, et. al. (the typical Unix solutions) use non-blocking i/o. If a network call does not complete immediately, the kernel does NOT do the i/o on behalf of the application. Instead, a worker thread (blocked on the kqueue, select, whatever) is awakened when the i/o can be reissued with the expectation of completing. The application must reissue the i/o. Async i/o 'saves' reissuing the i/o call, but the complexity with true async i/o as compared to non-blocking i/o make async a PITA to deal with. I really don't like Windows async i/o; it's too damn complicated. If you ever feel up to poking around in the windows MPM, you will see a lot of the infrastructure needed to make it an async MPM. I'm thinking I will just add a config option to the MPM to make it run in async mode. Someday when I have free time :-) The ultimate in coolness would be to create an APR API that hides all the nasty implenmentation details under the covers. Bill > On Tuesday 04 December 2001 10:47 pm, Justin Erenkrantz wrote: > > It has always been a problem of timing. After 2.0 is released, I plan > to look at creating an MPM for async I/O. And unless this requires > massive code changes, I would expect it to go in a 2.0 release. > > This is the type of thing that we should be doing after 2.0 is finally > made a GA release, look for cool ways to use the current architecture > to do new things. > > Ryan > > > [ Moving this to dev@httpd since I think this is not yet an > > APR issue. The app needs to drive this, not the portability > > library. ] > > > > On Tue, Dec 04, 2001 at 11:09:11PM -0500, Bill Stoddard wrote: > > > The idea is to never allow your threads to block doing network i/o. Do > > > all your reads/writes with non-blocking (or asynchronous) i/o. > > > > Considering I'm a newbie here, I've just spent a lot of time in > > the archives looking at what you guys have said before about > > trying to do async I/O in httpd. > > > > So, can someone tell me why we haven't done this before? It > > sure isn't because no one has wanted to. It keeps popping up > > every year or so since 1997. What has been the killer? > > > > I see a tremendous amount of posts around June/July 1999 about > > work on async-server hybrid (ASH MPM). However, I can't find > > what happened to the bugger. Dean kept talking about it, but > > obviously something happened to halt it. > > > > <[EMAIL PROTECTED]> > > http://www.apachelabs.org/apache-mbox/199906.mbox/%3cPine.LNX.3.96dg4.99061 > >[EMAIL PROTECTED]%3e > > > > <[EMAIL PROTECTED]> > > http://www.apachelabs.org/apache-mbox/199906.mbox/%3cPine.LNX.3.96dg4.99061 > >[EMAIL PROTECTED]%3e > > > > I wish we had a web page that listed "frequent topics" and > > their point/counterpoints. I don't want to go down any road > > that has already been covered. And, seeing the posts in this > > timeframe leads me to believe that almost every point has been > > covered. -- justin > > -- > > ______________________________________________________________ > Ryan Bloom [EMAIL PROTECTED] > Covalent Technologies [EMAIL PROTECTED] > -------------------------------------------------------------- >
