Oplock bug?

[James Peach]

On Mon, Jul 18, 2005 at 12:44:58PM -0700, Jeremy Allison wrote:
> On Mon, Jul 18, 2005 at 11:42:11AM -0700, Jeremy Allison wrote:
> > 
> > Sorry Volker, looks like this is a bug you introduced when simplifying the
> > code.... :-(.
> 
> Ok, looking closely at this - you ran into one of my paranoia
> defenses when I was creating the original code. There is no
> real reason to keep an independent count of the number of
> outstanding oplocks - only paranoia to ensure the numbers
> match. We could just ignore that test and debug statement
> and always call oplock_break(), which would return True
> on not finding the oplock - then return the message 
> and the logic would look much simpler.
> 
> I apologise for how obscure this logic was - but you have
> to remember I was creating this code whilst working out
> the correct logic, and so keeping a separate count allowed
> be to put independent debug checks in place (like the one
> you ran into) that confirm the underlying logic in two
> different places.
> 
> It should be much better when your tdb messaging replacement
> is in place for 3.0.21 and I'm looking forward to that.

Is the tdb messaging replacement code in trunk?

-- 
James Peach | jpeach at sgi.com | SGI Australian Software Group
I don't speak for SGI.