Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Message-ID: <029201bfa48f$c7700870$c1e01b09@raleigh.ibm.com>
From: "Bill Stoddard" <stoddard@raleigh.ibm.com>
To: <new-httpd@apache.org>
Subject: Should ap_bread et. al. be modified to work with async i/o APIs?
Date: Wed, 12 Apr 2000 11:00:02 -0400
Organization: IBM Corp.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Does it make sense to modify the buff code (ap_bread, et. al) to directly
handle async I/O? As Dean mentioned earlier, this requires buf to maintain
more state information. Here is the reason I'm asking...

The anonymous pipes Windows uses to talk to CGI scripts are always blocking
(and cannot be set non-blocking). I'm trying to fix this in Apache 2.0 and
have gotten bogged down in uglyness.

Named pipes (available on NT) allow asynchronous pipe i/o. My original
thought was that I'd implement async pipes in APR and do what was needed to
give them a non-blocking API semantics. It cannot be done without buffering
the async pipe I/O inside APR. More storage, more data moves, more
complexity. Bleh.  I am looking for alternative solutions. One alternative
is to modify the buf i/o code to handle async i/o (I'm not quite sure how to
start though).

There is yet another solution; use the PIPE_NOWAIT function in named pipes
and maintain the non-blocking symantics.  I'm not sure if MS discourages
this or not. The doc says PIPE_NOWAIT should not be used to implement async
i/o. Well duh, non-blocking and async are different beasts. I don't think
that's what they really ment though (I intuit this from the other doc in
MSDN).

________________________________________________
Bill Stoddard stoddard@raleigh.ibm.com