apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Re: filtering huge request bodies (like 650MB files)
Date Fri, 12 Dec 2003 04:35:28 GMT
I've been thinking the same thing driving around this evening...

One major goal of httpd-3.0 is *finally* arriving at something that starts
looking async.  We've kicked it around some time, but perhaps it's time
to start looking at the async poll implementation, to get some idea of how
we can 'poll' on multiple sorts of events.

The one thing that is clear to me, pre-1.0:  win32 needs to be able to poll
pipes and sockets, *even* if it means a really lame 100ms timeout (perhaps
configurable) on the socket poll to look sideways at the pipe info.  There is
no way to solve any of these problems without clearing that first hurdle.

But you brought up a great point - what about some notification signals?
How do we extend 'poll'.  It sure looks like we need something more clever
than a wrapper around posix poll/select.


At 02:52 PM 12/11/2003, Aaron Bannert wrote:
>On Thu, Dec 11, 2003 at 01:50:46PM -0600, William A. Rowe, Jr. wrote:
>> But the 2.0 architecture is entirely different.  We need a poll but it's not entirely
>> obvious where to put one...
>> One suggestion raised in a poll bucket: when a connection level filter cannot
>> read anything more, it passed back a bucket containing a poll descriptor as
>> metadata.  Each filter passes this metadata bucket back up.  Some filters
>> like mod_ssl would move it from the connection brigade to the data brigade.
>At one level we'll have to fit whatever I/O multiplexer we come
>up with in the filters. I'm going to stay out of that discussion.
>At a lower level, ignoring filters for a moment, we still need a
>way for applications to be able to multiplex I/O between different
>I/O types: pipes, files, sockets, IPC, etc... I think this is the
>root of the problem (and something we should probably move over
>to the dev@apr list, and also something we might want to take up
>after APR 1.0 is released).

View raw message