httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject 2.0 Scoreboard (was Re: Management of thread pools)
Date Sat, 19 Jun 1999 00:12:10 GMT
On Mon, Jun 14, 1999 at 11:36:22AM -0400, Ryan Bloom wrote:
> This idea of having a dynamic thread-pool still seems like a bad idea to
> me.  I have no problem if it can be done well, but I don't think Unix
> threads are up to that task yet.

The idea is just to try it out; if it doesn't work, it doesn't work.

The reason I asked the question in the first place is that it will be
important for deciding how a rearchitected scoreboard will work.

We've talked about tearing a lot of the stuff out of the current
scoreboard and putting it into some sort of query function. If we do
this, the best things to put in the scoreboard are stats needed to
manage the server pool, because we don't want to require the parent to
query every child every second (right?)

So, we need to decide what these stats are. And this depends on what
the proper way to manage the threads and processes is.

If we have the parent decide globally what to start and stop, then we
have to give it info on how busy the processes are. But, if the server
doesn't keep per-thread stats, then every thread will have to
serialize on touching a process-busy state field in the scoreboard.

That's the benefit of having each process manage its own thread-pool;
there's less scoreboard activity, and less cross-process serialization

Another option would be a less major tweak. The scoreboard would keep
per-thread stats instead of per-request stats. Then, each thread can
interact with the scoreboard as it does now, with no synchronization.
The scoreboard wouldn't be humongous in the async request handler
model Dean's doing, but it wouldn't be small either.

Manoj Kasichainula - manojk at io dot com -
"'Why do you blow on people?' I don't know." -- Benny Hinn

View raw message