Ryan Bloom wrote: > 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.
How about giving the read-from-filter-stack code the ability to read
from more than one stack simultaneously?
The basic idea would be that you would read from one or more stacks
(where now you can only read from one stack). The read would return a
brigade, and a variable to say which stack the brigade came from. It
would be up to the calling code to decide intelligently on what to do
with the brigade based on which stack it came from.
This way a proxy might implement request pipelining. One or more
requests would arrive via Apache's framework, and as they arrived the
proxy could kick off possibly more than one request to possibly more
than one backend. It would then read from the backends, and possibly
buffer the content, before pipelining it in the correct sequence to the
client. If the backends were slow, this could offer a significant
performance improvement, as the backend would not have to wait till
request A is finished before starting the generation of request B.
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED] "There's a moon
over Bourbon Street
tonight..."
smime.p7s
Description: S/MIME Cryptographic Signature
