Re: Why do we have NONBLOCK bucket reads? (or, "I want poll for buckets")

[Aaron Bannert <aa...@clove.org>]

On Wed, Mar 06, 2002 at 07:32:57PM -0500, Bill Stoddard wrote:
> 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 :-)

Hmmm...I just had a partial brain dump of what I've been thinking
through today, but I ended up discarding that idea. Here's what
I've been mulling over today:

Basicly, I think we would have to come up with a bunch of
apr_bucket_poll*() calls that mostly mirror the apr_poll*()
functions. Under the covers we could actually call apr_poll()
when the foremost bucket on a brigade was a FILE, PIPE, or SOCKET;
and if any other foremost-buckets on a brigade in the set were of
another type we would treat it as an event.

My first impression of this model is that we're going to have a huge
amount of overhead on each apr_bucket_poll() call, since internally
we'd have to run through every brigade and build a pollset from that,
returning on any non-blockable bucket. The next question is to determine
if this is feasible, or if there is a better way.

-aaron