httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: concurrent ssl context access
Date Tue, 12 Jul 2016 08:37:30 GMT

> Am 11.07.2016 um 17:38 schrieb William A Rowe Jr <>:
> On Mon, Jul 11, 2016 at 5:25 AM, Stefan Eissing <>
> In the issue crept up that StdEnvVars
makes concurrent access to the SSL context when HTTP/2 is in place.
> The question is: how do we want to fix this?
> The general theme is that a module needs to perform some action on a connection, sees
that it is a slave connection and accesses the master instead. Such a module needs to be aware
that access to master may happen in parallel with other request.
> Should we let each such module care for it on its own or do we want to provide a way
to access the master connection in a mutex protected way?
> Rather than a mutex, which would become an issue because all master access
> to the context would require blocking, is there a way we can allow a module to
> perform its (hopefully swift) processing on the master thread? Send a metadata
> bucket to the master asking for a function to be invoked?

Hmm, interesting idea. Of course, there would still be a mutex involved in handling such a
query, but maybe it can be done more elegant than mutexing all accesses to structures everywhere.

One way to look at this is that information retrieval from slave to master is something like
a GET and that information injection into the master conn is something like a POST. So, effectively
(and not necessarily in HTTP wire format), a slave connection would to a

GET /ssl/StdEnvVars

to retrieve the map. Which would, the first time, get added to the incoming queue on the master
thread, be answered, slave thread awoken again and processing continues. This would be cached
for future queries, so that slaves can access it without being put to sleep.

We could use our famous HOOK infrastructure so that modules can register their own handlers
for such information. We'd only need to nail down the general semantics and the data format
for interchange. Something like a const apr_table_t would probably work. It would need to
be readonly and allow concurrent use.

View raw message