From: <[EMAIL PROTECTED]>
Sent: Sunday, April 22, 2001 10:34 PM
> FirstBill saiz
> >
> > I agree with you Ryan. Haven't thought about this much over the weekend, but my
>inclination is that
> > a combination of strategies is required. First, split the scoreboard into two, one
>for process
> > management and one for status. The process management scoreboard will be small
>enough to enable us
> > to overcommit processes to compensate for multiple processes being restarted at
>once. Then as Greg
> > suggests, put some bounds on the number of process that may be in restart.
>
> I am 100% on board with splitting the scoreboard. I disagree with putting
> bounds on the number of processes allowed in restart however. I don't see
> how it is possible to get around the problem outlined above. I haven't
> really thought it through though, so I could easily be missing something.
Given the nature of our headache, what about simply basing each threaded cluster
[process]
in it's own scoreboard (that dies when that process and whatever-dozen thread children
go away) and a master 'index' to the scoreboards across processes?
This would have been a damned stupid design with 500 processes (single threaded) but
makes
a heck of a lot of sense for 5 processes of 100 children (which grows to 10 processes
as
the 5 are spun down and 5 new ones are spinning up.)
Bill
