On 07 Feb 2014, at 5:34 PM, Jim Jagielski <[email protected]> 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. Regards, Graham --
