It seems like a lot of the scoreboard confusion lies in the event MPM lies in the work-performed-by-thread model of the thread based scoreboard.
Let's call this existing model 'ExtendedStatus threads' What it seems some users and committers are looking for is a different model, let's call this 'ExtendedStatus connections'. If we adopted an ExtendedStatus connections, the scoreboard table would be much larger than the number of event threads, and would report all of the open connections to the server (at least, all those that had passed the httpready threshold of our awareness). It can't be a simple ring, because the slots would expire at different times relative to their injection, so we would probably want to track the oldest request. The most optimal implementation would have score pools per-process so that connection score slot reuse is a simple thread lock, but we could alternately perform this tracking across processes. The first question that comes to mind is whether there is any value in supporting ExtendedStatus threads+connections? Two entire detailed lists residing in two different score shms? Note that the traditional thread status flag scoreboard would certainly be preserved, for a thread summary, even when the user chooses ExtendedStatus connections. Feedback and more ideas? Cheers, Bill
