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). On Feb 7, 2014, at 9:55 AM, Graham Leggett <[email protected]> wrote: > On 07 Feb 2014, at 3:54 PM, [email protected] wrote: > >> Author: jim >> Date: Fri Feb 7 13:54:38 2014 >> New Revision: 1565657 >> >> URL: http://svn.apache.org/r1565657 >> Log: >> Add in the concept of "slave" connections... >> Allows for several "connections" all resulting in >> a single real connection that talks to the network. >> Right now, nothing uses this though. > > Nice. > > We also need the option to associate an arbitrary socket[1] to the slave > connection, which could be created by mod_proxy, obtained from a connection > pool, etc. I guess that is further down. > >> +/** Create a slave connection >> + * @param c The connection to create the slave connection from/for >> + * @return The slave connection >> + */ >> +AP_CORE_DECLARE(conn_rec *) ap_create_slave_connection(conn_rec *c); > > How would we handle a connection pool scenario? > > Here, we arrive, grab a connection from our pool, now we need to associate it > with the frontend connection somehow. Ideally the pool cleanups should cover > all the scenarios of tearing this down, returning to the connection pool, etc. > > It depends on whether it is worth teaching the core how to be aware of > connection pools, or if that is a step too far. > > Regards, > Graham > -- >
