For the next 2.4 release, I would like to add scoreboard support to mod_http2.
There are several options for doing so and I would like your feedback on which
route we should take. I try to outline what options I see:
A) Make mod_http2 workers general MPM workers. They would then become
part of scoreboard without changes to the board itself.
B) Extend scoreboard to handle "thread sets", where MPM threads are the set it
has
not. mod_http2 would register a new set. scoreboard handles, an opaque struct
pointer for everyone, would get an additional "set id".
C) Mix both. MPM has thread sets and scoreboard learns to handle them.
Discussion:
1. A), doing it naively, will mess heavily with MPM module code. MPM modules now
use for(0...num_threads) {} heavily to setup threads that handle sockets and
pollsets and other nice things. This is not relevant for the http2 workers
which
are, framed more generally, "slave connection workers", whereas the current
MPM
threads are "master connection workers".
2. B) will not mess with MPM at all, just extend scoreboard and mod_status.
mod_http2
would register itself for a new thread set and update the status regularly.
This
approach offers least API disturbance for a backport to 2.4.x
3. C) is an extension of B). Thread sets get registered at MPM, scoreboard
interrogates
the new MPM sets and can hand out "scoreboard handles" for them. Bringing
these sets
into the MPM could be done, so that spare threads are shared between
different sets.
Don't know if that's desirable.
4. For mod_http2, the existing status indicators will continue to work, as
slave
connection workers do the same tasks as MPM threads, more or less. For more
flexible
use, one could provide for status indicators provided by the registrar.
Thoughts?
//Stefan
