Okay, this is a bug in the implementation, not the design.  As I tried to explain,
the design does not allow for this.  We should fix the bug in the code, not reinvent
the design again.

As it happens, moving to a single-listen/multi-acceptor model allows us to fix this bug
FAR easier, because we can always have the listen thread in the t0 slot for a given 
process.
Then, when we want to determine if a process is shutting down, then we just check the 
t0
slot.

Today, we check all threads, which is a bit bogus.

Ryan


On Friday 27 July 2001 12:12, Jeff Trawick wrote:
> Ryan Bloom <[EMAIL PROTECTED]> writes:
> > As I have tried to explain MUTLIPLE times, we do not have two workers
> > fighting over the same field.  The threads are always separated
> > correctly.  We can have to processes using the same process_score, but
> > that only affects the pid, generation, and sb_type.  The only thing that
> > matters in that case is the pid, and that is easily fixable, by moving it
> > to the worker_score where it belongs.
>
> t0:
>
>   some thread slot is SERVER_DEAD so parent forks a new child (call it
>   "X") to take over that set of slots
>
> t1:
>
>   "X" is not done initializing
>
>   some thread slot is SERVER_DEAD so parent forks a new child (call it
>   "Y" to take over that same set of slots
>
> t2:
>
>   start_threads() in process "X" sees that an entry is SERVER_DEAD and
>   gets timesliced just before starting a thread to take over that
>   entry
>
> t3:
>
>   start_threads() in process "Y" sees that same entry is SERVER_DEAD
>   and starts a thread to take over that entry
>
> t4:
>
>   process "X" wakes up again and takes over that entry
>
> we now have threads in two different processes using the same slot
>
> Even if the threads were always separated correctly, which they
> aren't, why would we allow more than one process to take over the
> slots for a dying process?  That uses more system resources.

-- 

_____________________________________________________________________________
Ryan Bloom                              [EMAIL PROTECTED]
Covalent Technologies                   [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to