Yes, that is right. SOME modules can grab the context for *other*
modules (proxy does this), but in general, the context is related
to *this* connection for *this* module.
> On Mar 3, 2016, at 10:30 AM, Stefan Eissing
> wrote:
>
>
>> Am 03.03.2016 um 16:21 schrieb Yann Ylavic :
>>
>> On Thu,
On Thu, Mar 3, 2016 at 4:30 PM, Stefan Eissing
wrote:
>
> Some ap_conf_vectors are populated by the runtime for all modules
> participating (like server_rec->module_config), some are not. The ones in
> conn_rec ->conn_config are only directly set by a module and the module
> determines what doe
> Am 03.03.2016 um 16:21 schrieb Yann Ylavic :
>
> On Thu, Mar 3, 2016 at 3:57 PM, Jim Jagielski wrote:
>>/** Config vector containing pointers to connections per-server
>> * config structures. */
>>struct ap_conf_vector_t *conn_config;
>
> Yes, this is opaque, and turns out to be
Forgot to mention that it's created w/ ptrans which is c->pool
> On Mar 3, 2016, at 9:57 AM, Jim Jagielski wrote:
>
>/** Config vector containing pointers to connections per-server
> * config structures. */
>struct ap_conf_vector_t *conn_config;
>
On Thu, Mar 3, 2016 at 3:57 PM, Jim Jagielski wrote:
> /** Config vector containing pointers to connections per-server
> * config structures. */
> struct ap_conf_vector_t *conn_config;
Yes, this is opaque, and turns out to be a implemented as void**.
We could even make it a struct i
/** Config vector containing pointers to connections per-server
* config structures. */
struct ap_conf_vector_t *conn_config;
On Wed, Mar 2, 2016 at 5:20 PM, Graham Leggett wrote:
> On 02 Mar 2016, at 2:26 AM, Yann Ylavic wrote:
>
Would it make sense to add a vector of contexts that same way we have a
vector of configs, one slot for each module, which will allow any module
to add a context of it’s own t
> Am 02.03.2016 um 17:20 schrieb Graham Leggett :
>
> On 02 Mar 2016, at 2:26 AM, Yann Ylavic wrote:
>
Would it make sense to add a vector of contexts that same way we have a
vector of configs, one slot for each module, which will allow any module
to add a context of it’s own t
On 02 Mar 2016, at 2:26 AM, Yann Ylavic wrote:
>>> Would it make sense to add a vector of contexts that same way we have a
>>> vector of configs, one slot for each module, which will allow any module to
>>> add a context of it’s own to conn_rec without having to extend conn_rec?
>>
>> Can't th
exit in the expectation of being called again
>> when an async mpm is present - this is easy, the mpms already do that.
>>
>> The missing bit is that conn_rec needs a context so that when is is called a
>> second time it knows what state it is in.
>>
>> There is a
, the mpms already do that.
>
> The missing bit is that conn_rec needs a context so that when is is called a
> second time it knows what state it is in.
>
> There is a void *ctx variable that was added in r1565657, but I’m not sure it
> is enough.
>
> Would it make sense
On Wed, Mar 2, 2016 at 1:23 AM, Yann Ylavic wrote:
> Hi,
>
> On Wed, Mar 2, 2016 at 1:09 AM, Graham Leggett wrote:
>>
>> Would it make sense to add a vector of contexts that same way we have a
>> vector of configs, one slot for each module, which will allow any module to
>> add a context of it’
Hi,
On Wed, Mar 2, 2016 at 1:09 AM, Graham Leggett wrote:
>
> Would it make sense to add a vector of contexts that same way we have a
> vector of configs, one slot for each module, which will allow any module to
> add a context of it’s own to conn_rec without having to extend conn_rec?
Can't t
Hi all,
In order to get connections to have async behaviour, it must be possible for
the process_connection hook to exit in the expectation of being called again
when an async mpm is present - this is easy, the mpms already do that.
The missing bit is that conn_rec needs a context so that when
14 matches
Mail list logo
