> Am 11.07.2016 um 17:42 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > On Mon, Jul 11, 2016 at 10:38 AM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > On Mon, Jul 11, 2016 at 5:25 AM, Stefan Eissing > <stefan.eiss...@greenbytes.de> wrote: > In https://bz.apache.org/bugzilla/show_bug.cgi?id=59840 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? > > (Note that the ask of interrogating the ssl context for stdenvvars itself by > the > child request is a pretty sub-optimal solution. mod_ssl itself should gather > and set this data aside once (and once again, upon renegotation) for our > concurrent, un-mutexed reference in the child request.)
I think there should be env vars attached to conn_rec which get copied to the vars for a request_rec. If anyone has a good idea how to bring that into existence, I'm all for it.
