On Monday, April 16, 2001, at 01:09 PM, <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Apr 2001, Chuck Murcko wrote:
>
>>
>> On Monday, April 16, 2001, at 11:00 AM, <[EMAIL PROTECTED]> wrote:
>>
>>> ...Paul...
>>> Allow me to offer another idea. What if we create temporary process
>>> for
>>> this case. The idea is that when we are shutting down, if processes
>>> get
>>> stuck with a couple of long-lived requests, then the parent checks the
>>> scoreboard to see how many contiguous locations there are in the
>>> scoreboard. It then creates a single process with that many threads.
>>> As
>>> more processes are required, we can create more temporary servers.
>>> Then,
>>> as soon as we can create a full process, we start to kill of the
>>> temporary
>>> process, and spawn new full processes.
>>>
>>> This solves your problem of having processes stuck in long-lived
>>> requests,
>>> and it solves the scoreboard issue too.
>>>
>>
>> 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.
Chuck
Chuck Murcko
Topsail Group
http://www.topsail.org/
