httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: Why do we have NONBLOCK bucket reads? (or, "I want poll for buckets")
Date Thu, 07 Mar 2002 00:32:57 GMT
Yep, you've nailed one of the big problems with the bucket/brigade API as it is currently
implemented. Remember a few weeks back when I talked about how interesting it would be if
our CGI interface could be made full-duplex? To do this, we need to be able to do
non-blocking i/o plus be able to detect i/o event notifications (via poll/select). We
probably do NOT want to do true async i/o. Async i/o is way complicated as compared to
event driven i/o using /dev/poll, kqenqueue/kqdequeue, etc., and event driven i/o achieves
most all of the interesting function anyway.

I am interested in working on adding a set of event driven APIs to APR, but I can't even
think about it until Apache 2.0 is released.... (I even have a prototype event driven
Apache 2.0 implemented on Windows that I shelved work on maybe 8 months ago.) If you come
up with a design, I'll certainly find time to review it :-)


> I see how these will be useful with an Async I/O model, but at the moment
> this read mode seems either incomplete or not useful. It seems to me like
> all current uses of NONBLOCK are probably unnecessary, since there is no
> other way to "wait" for data to appear other than spinning endlessly.
> The problem seems to be that we don't have a way to determine when that
> bucket read would no longer block once we've already determined that
> it would. I'm looking for a select()/poll() mechanism for a group of
> buckets. Does this even fix into our model? If not, how were we planning
> on making bucket brigades able to work with Async I/O?
> -aaron

View raw message