httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: 2.0 Scoreboard (was Re: Management of thread pools)
Date Sat, 19 Jun 1999 04:19:30 GMT
On Fri, Jun 18, 1999 at 05:28:58PM -0700, Dean Gaudet wrote:
> I showed a method whereby which one process can maintain a pool of threads
> large enough to service the current demand without a scoreboard... all it
> takes is a simple counter that goes along with the request queue.

Right, I'm not worried about that part.

> A similar trick can be done for processes... every second the parent wakes
> up and does a non-blocking select() on the listening fd, if it's marked
> ready for listen, then all the children are busy, so spawn another child. 

Hmmmm. That's a cool idea. This only lets us set a spare thread limit
of 1, though. Is that enough padding?

> How do you shrink the number of children?  Dunno, don't have a trick for
> that yet. 
> The 1.x scoreboard is a multicpu nightmare -- it causes cache lines to be
> whacked around from CPU to CPU... it just doesn't scale well. 

Don't most decent MP systems snoop the bus to pick up writes to RAM?

For shrinking the number of CPUs, we could check the scoreboard
rarely, say once per minute or 5 minutes. That's all we really need
for the shrinking case. If we give each process its own cache
line (can we determine cache line length programmatically?), and the
parent process checks the scoreboard rarely, the problem you describe
should be virtually nonexistant, right? Well, it'll do until we come
up with something better

> It's important to separate the two uses of the scoreboard.

I guess the purpose of my message didn't quite come through. :)

Another way to eliminate the idle counting necessity of the scoreboard
is to have a fixed number of processes, and to make each process run
its own thread pool. Each child would just add and delete threads
without changing the number of processesi or caring at all about what
the other processes are up to. This might cause thrashing, though,
with threads just dying in one process and starting in another.

Manoj Kasichainula - manojk at io dot com -
"Cheese is a useful thing, too. Should WebDAV have cheese?"
  -- Larry Masinter

View raw message