httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: svn commit: r1565657 - in /httpd/httpd/trunk: include/ap_mmn.h include/http_core.h include/httpd.h server/connection.c server/core.c
Date Fri, 07 Feb 2014 16:26:10 GMT

On Feb 7, 2014, at 10:58 AM, Graham Leggett <> wrote:

> On 07 Feb 2014, at 5:34 PM, Jim Jagielski <> 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.

View raw message