I would like to move the h2 worker pool into the mpm at some time in the future. To be available on systems with threads and non-prefork configurations.
The main motivation for this is that h2 workers have been so far "under the hood" of mod_http2. This makes them invisible to other parts of the system, like the scoreboard. On public fronting installations, h2 is now according to browsers and CDNs, outnumbering h1. This means their configuration has become more relevant and user need a way to monitor those. Also, should anyone ever start to tinker with a h3 implementation, such a worker pool would also become necessary. I think this should be a single instance. Duplicate pools for request processing do not make sense. Why a separate pool at all? Do not the mpms already have a worker pool? Yes, but we are not fully async. This means that an active worker on a primary connection is firing off many secondary connections to process. Would we try to run them in the same pool, we'd encounter deadlocks. Also, dimensioning would become difficult. Example: An mpm_event with 10 workers, 9 active TCP connections running. - this leaves 1 worker to handle the actual requests of 9 connections. Performance will be bad. - the mpm would accept a 10th connection and leave no worker available for secondary requests. The system stalls until timeouts trigger. This is avoided by using separate pools for primary and secondary connections. One could still encounter stalls with an under-dimensioned second pool, but it can be more easily and transparently managed. We should give the admin tools to monitor this second pool in the scoreboard, of course. Kind Regards, Stefan PS. Thinking the other direction: should http/1.1 requests also be run in the secondary worker pool? From some kind of purity point of view, this would make sense. It could be done. I just do not see the benefits at this point.
