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. Bill 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 [EMAIL PROTECTED] list, and also something we might want to take up >after APR 1.0 is released). > >-aaron
