On Jun 5, 2013 7:33 PM, Graham Leggett minf...@sharp.fm wrote:
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
--
