[rc5] Apparent serious bug in GUIWin32

dan carter daniel.carter at stonebow.otago.ac.nz
Wed Oct 1 20:24:08 EDT 1997


Phil Reed wrote:
> 
> In response to my message, "Ricki Lee King" <rlking at iquest.net>
> writes:
> >Subject: Re: [rc5] Apparent serious bug in GUIWin32
> >
> > what you are seeing is an effect of FILO.
> >the partial block will get done last unless
> >you keep doing GETS. then it will just sit
> >in the buffer forever waiting its turn.
> 
> This is inconsistent. If I just stop and start the client, then
> tell it to begin working with current settings, it resumes the block
> that I interrupted.
Yes, thats LIFO

Here comes a fuller description of whats going on.

You download two blocks, and so your buff.in looks like:
Buff-in:1,2
then you start processing a block
Buff-in:1
you stop halfway
Buff-in:1,2   plus a note attached to block 2 saying its partly
processed.
then you start and it picks up block 2 again, and resumes.

Alternatively
You download two blocks, and so your buff.in looks like:
Buff-in:1,2
then you start processing a block
Buff-in:1
you stop halfway
Buff-in:1,2   plus a note attached to block 2 saying its partly
processed.
Then you fetch two more
Buff-in:1,2,3,4 (plus the note on 2)
You start again and the client picks up block 4 and starts from the
start of block 4. Eventually it will pick up block 2 again and resume it
where it left off processing block 2.

ie. the buffers are a pile, the client picks off the top of the pile
when it wants one to crunch, and it dumps on the top of the pile when it
fetches more, burying the existing blocks.
ie. FILO: the First one In is the Last One out.
Ideally a fetch would place them on the bottom of the queue but it
doesn't. Nevermind it still works.
----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.



More information about the rc5 mailing list