On Monday, April 16, 2001, at 02:33 PM, <[EMAIL PROTECTED]> wrote:
>
>>>> What about the converse? Moving the old process/threads out of the
>>>> scoreboard and into a "dying" temp area, and creating a new
>>>> scoreboard
>>>> entry for the old proc/thread entries.
>>>>
>>>> It seems safer (less potentially recursive, but a little slower).
>>>
>>> The problem with this, is that you take a very large chance that you
>>> will
>>> create more processes than you are supposed to.
>>>
>>
>> Sorry I was thinking "overlaying the scoreboard" when I wrote "creating
>> new scoreboard entry" and no the latter is not the way to do that. The
>> former minimizes the amount of scoreboard-type data being kept outside
>> the scoreboard.
>
> The problem with overlaying the scoreboard, is that you have to
> introduce
> synchronization in order to do it. You also need to modify how
> processes
> figure out where to store their scoreboard entries. As soon as you
> move a
> scoreboard entry from it's default location to a new place in the
> scoreboard, you are introducing a big headache.
>
Mmm, was thinking not of moving within the scoreboard, just copy out the
few active threads with the old dying process and copy over all those
entries for new.
Must be synchronous, as you point out.
Can your idea handle broken processes with a couple of hung threads? Is
there a whole temp scoreboard, or just the overflow processes?
Chuck Murcko
Topsail Group
http://www.topsail.org/
