I really want to spend some time on this (when I have some time to spend on it). As part of this work, we need to consider what needs to be done to the filter API to support an event driven MPM. Need to get this prioritized above the other stuff I'm working on :-(
Bill > > 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. > > Ryan > >
