Hi Stefan, On Fri, Mar 20, 2015 at 2:19 PM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > > Looking at the code in httpd, mpm_worker and mpm_event seem to create own > alloctors for the pools they use and those allocators are not protected by a > mutex. And need not, since normally a connection and all its sub-requests run > in the same thread, right?
This is true for 2.4.x, however in trunk one (handler) can register a socket callback and return SUSPENDED, for the event MPM to do all of the poll()ing stuff and provide a worker thread for the callback when sockets are ready (either way). There is an example on how this can be used in mod_proxy_wstunnel (when "ProxyWebsocketAsync on" is configured), in trunk only (still) so it may not be very tested. I think it suits quite well the async nature of http/2 (with a state machine in the callback for the real work, and all the polling and threading handled by httpd), maybe it's worth a try. It does not help on the pool issues you have got now though, maybe some work is needed in HTTP/SSL/core input/output filters so that they use the pool/allocator of their given buckets brigades (instead of eg., r->pool and c->bucket_alloc), since multiple threads working on the same connection is not really a possibility in httpd (for now...). Thanks anyway for the great explanation on how mod_h2 works. Regards, Yann.