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 :-) Bill > 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 >
