I'm reading the sam source (very educational) and I've stumbled across
a piece I don't understand, in buff.c:^bufreset:
for(i=b->nbl-1; --i>=0; )
delblock(b, i);
Doesn't this delete b-nbl-1 blocks? Also delblock would always call
memmove, moving 1 block at the end, if I read it correctly.
But delblock only calls memmove if i is less then b->nbl, which was
just decremented, correct?
So isn't the memmove just to cover the case where you are
deleting a block that isn't at the very end?
Jim
> So isn't the memmove just to cover the case where you are
> deleting a block that isn't at the very end?
Yes, but from what I understand i is always lower.
Say b->nbl starts at 10. i=b->nbl-1 so i=9. --i so i=8.
Inside delblock b->nbl-- so b->nbl is 9. i wrote:
> But delblock only calls memmove
On Fri, Aug 12, 2016 at 8:32 AM Costin Chirvasuta wrote:
> > So isn't the memmove just to cover the case where you are
> > deleting a block that isn't at the very end?
>
> Yes, but from what I understand i is always lower.
>
> Say b->nbl starts at 10. i=b->nbl-1 so i=9. --i so i=8.
> Inside delbl
Sorry, you're right, delblock(b, 0) is called. delblock(b, 9) isn't
called. It's called for the sequence 8..0, as you stated.
So is this correct? Doesn't this mean one block will never get
released back to the temporary disc?
On Fri, Aug 12, 2016 at 6:48 PM, James A. Robinson
wrote:
> On Fri, Au
Have you checked whether or not that final block is
special in some way? For example only mapped to
memory and not to disk blocks?
Jim
I believe bufreset can be called at any time and b->cbi (the current
cached block) can point to anything.
Either way, that block is never returned to the Disc's free list so
that file address won't be reused from that point on.
On Fri, Aug 12, 2016 at 7:16 PM, James A. Robinson wrote:
> Have you
