On Feb 7, 2014, at 10:58 AM, Graham Leggett <minf...@sharp.fm> wrote:
> On 07 Feb 2014, at 5:34 PM, Jim Jagielski <j...@jagunet.com> wrote: > >> These are all good questions, and I'm not sure what the >> answer is right now... another one, maybe ap_run_create_connection >> should return a *slave* connection (it creates both master >> and its slave, but returns the slave). That would be much >> more flexible for the MPM and the process_connection >> phase, but would mean that core needs to Do The Right Thing. >> >> But then again, why add that complexity if you don't need >> it? That's what the hooks are for and if we need to create >> slave connections, that's what pre_connection is for (and >> how mod_spdy currently handles it). > > True. > > Thinking out loud I am wondering what the right layer is to do this at. > > Ideally I would like to, at any time, for any reason, go "here is a conn_rec > that already exists, add it to this group of conn_rec's in the event loop, > treat this conn_rec like any other connection moving forward, go". > > How that conn_rec leaps into existence should in theory not matter, maybe > mod_spdy made some of them in one go, maybe mod_proxy grabbed one from a > pool, shouldn't matter. > > Ideally the "add this conn_rec to the event loop" should have appropriate > pool cleanups such that it is automagically removed from the event loop if > that conn_rec is destroyed. > > There also needs to be a way to actively remove a conn_rec from the event > loop, so that mod_proxy can return a connection to a pool when done. > Some kind of callback for each conn_rec, such that when we are "done" with it, it knows what do to (rejoin mod_proxy's pool, pool cleanup, whatever). In some ways, the "slave" connection actually behaves like a router, between the request and the "real" connection... it would also be nice to remove the thread-specific stuff to this slave connection.
