On 05 Jun 2013, at 3:00 PM, Eric Covener <cove...@gmail.com> wrote: > I've been playing with this in my sandbox, it adds a "socket readable" > callback to event, similar to the timed callback, which allows > mod_proxy_wstunnel to hop on and off the thread like test/mod_dialup. > > http://people.apache.org/~covener/websocket-asynch-8.diff
I was meaning to play around with a similar idea, but you beat me to it. What I had in mind was an API that passed conn_rec structures rather than raw sockets, which could then be processed using the same lifecycle that a server generated conn_rec's pass through (ap_run_process_connection()). Proxy could then pass the conn_rec it uses towards the backend to the core, and then obtain event driven events for ready-to-read and ready-to-write from the frontend and the backend, independently of one another. > The weird API for the socket callback, which treats a set of sockets > as a group and only callbacks once per group, is to avoid hairy > situations where something like wstunnel or mod_proxy_connect sees > callbacks after the request has finished (or has to make sure this > doesn't happen and use longer-lived pools for state). In theory these callbacks should be automagically registered with a pool cleanup, and should in theory be cleaned up automatically. It would be up to the caller to specify what pool they plan to tie the lifetime to. This is how conn_rec and request_rec work, ideally any new API should work the same way. The callbacks-as-a-group idea is really nice, what I've always wanted is a way to say "call me when socket X is readable and socket Y is writeable", so I don't waste a lot of time trying to figure this out for myself. Regards, Graham --
smime.p7s
Description: S/MIME cryptographic signature
