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
