Design change for oplock/open code?

[Jeremy Allison]

On Thu, Apr 11, 2013 at 11:06:03AM +0200, Volker Lendecke wrote:
> Hi!
> 
> Attached find a patch that is NOT for upstream yet, but what
> I would like to receive some comments for.
> 
> It changes our oplock and open retry handling logic. The
> first of the patches adds a dbwrap_record_watch_send when we
> defer an open. For those who haven't seen this API yet: It
> calls us back whenever a record we're interested in changes.
> It is right now used in the g_lock implementation for
> persistent ctdb transactions as well as the smb2 session
> reconnect code.
> 
> With current code, for oplock breaks we rely on the code
> that handles the client oplock break to get back to us when
> the oplock break is done. Likewise for the SHARING_VIOLATION
> retry when a file is closed. The new code will retry the
> open whenever the locking.tdb record changes, independently
> from the oplock breaker or conflicting share mode holder. It
> might lead to some false wakeups, because someone unrelated
> modifies the record, but I right now I can't think of a
> scenario where this could become a problem.
> 
> Two nice aspects: First, the patchset just survived an
> autobuild. Second, it has the potential to decouple
> responsibilities and remove quite some code, simplifying our
> oplock implentation somewhat.
> 
> Comments?

Oooh. I really like this. Please develop further :-).

Jeremy.