Ryan Bloom wrote: >>From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] > >>Bill Stoddard wrote: >> >> >>>This is a variation of the problem Aaron and I were interested in >> > with > >>CGI scripts (and >> >>>directly related to an open PR against 2.0.36). Unfortunately, I >> > think > >>filters need some >> >>>more work to make this possible. As Will said, we need to be able to >> >>poll/select on both >> >>>the frontend and backend descriptors and do the right thing. I may >> > be > >>mistaken but I >> >>>thought the proxy in 1.3 handled this correctly... >> >>The v1.3 proxy was always read request then read response, it never > > did > >>these two simultaneously. >> >>Would the changes to the filters be that drastic? We would in theory >>just have to poll for incoming data (in either direction), then read >>bridages from the relevant filter stack...? No...? > > > I tried to think through how to do this back in November, when I last > touched the proxy. The easiest way to do this, is to add a new read > mode to input filters, APR_READ_POLL. Each filter would be responsible > for returning any data that it has if called in this mode. If none of > the filters in the stack have any data, then the filter that has the > socket must return the socket bucket, but it is allowed to keep a copy > of the socket itself. The filter_poll call can then use apr_poll to > determine which of the sockets have any data. This wouldn't be the > cleanest code, but it should work.
Seems to me that you really want a apr_poll equivalent that works on bucket brigades - that would make this clean, and could be quite elegant (IMO). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
