Async IO was Re: Pools rewrite [2]

[Justin Erenkrantz <je...@ebuilt.com>]

[ 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.

<Pi...@twinlark.arctic.org>
http://www.apachelabs.org/apache-mbox/199906.mbox/%3cPine.LNX.3.96dg4.990618090647.27639I-100000@twinlark.arctic.org%3e

<Pi...@twinlark.arctic.org>
http://www.apachelabs.org/apache-mbox/199906.mbox/%3cPine.LNX.3.96dg4.990619160004.27639b-100000@twinlark.arctic.org%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

Re: Async IO was Re: Pools rewrite [2]

[Bill Stoddard <bi...@wstoddard.com>]

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.
> >
> > <Pi...@twinlark.arctic.org>
> > http://www.apachelabs.org/apache-mbox/199906.mbox/%3cPine.LNX.3.96dg4.99061
> >8090647.27639I-100000@twinlark.arctic.org%3e
> >
> > <Pi...@twinlark.arctic.org>
> > http://www.apachelabs.org/apache-mbox/199906.mbox/%3cPine.LNX.3.96dg4.99061
> >9160004.27639b-100000@twinlark.arctic.org%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 rbb@apache.org
> Covalent Technologies rbb@covalent.net
> --------------------------------------------------------------
>

Re: Async IO was Re: Pools rewrite [2]

[Ryan Bloom <rb...@covalent.net>]

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.
>
> <Pi...@twinlark.arctic.org>
> http://www.apachelabs.org/apache-mbox/199906.mbox/%3cPine.LNX.3.96dg4.99061
>8090647.27639I-100000@twinlark.arctic.org%3e
>
> <Pi...@twinlark.arctic.org>
> http://www.apachelabs.org/apache-mbox/199906.mbox/%3cPine.LNX.3.96dg4.99061
>9160004.27639b-100000@twinlark.arctic.org%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				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------