[PATCH]: Windows BRL Try 2

[Jeremy Allison]

On Wed, Feb 18, 2009 at 03:49:43PM -0800, Zack Kirsch wrote:
> You hit it on the head there - that's what I'd prefer to do, but I'm
> still stuck wondering what to do with the LockingX logic, in order to
> keep it the same as it is now. I don't think the logic would be quite
> the same if we only passed a timeout parameter from LockingX, since it
> literally changes the timeout variable in the middle of the two
> sync/async calls. Perhaps we could simplify the LockingX
> timeout/deferral logic?
> 
> The NT_STATUS_FILE_LOCK_CONFLICT case is particularly interesting. :)

I think the rescheduling/spinning logic should be the
same for all the potential locking calls, not just LockingX
(but also lockread, lock etc.) although we'd need to
add torture tests to make sure this is also the case
on Windows. I doubt that the lock timeouts are
handled differently accross these calls.

In the worst case we'd have to pass a "is_lockingX"
parameter down over the VFS API to deal with different
timing semantics, although as I say I doubt that's
needed.

The logic should be identical if we just move
the same rescheduling/spinning code under the
default VFS (POSIX) implementation for Windows lock. That
way a filesystem that actually does the real Windows
lock semantics just gets the raw data it needs
to do "the right thing" (ie. if your filesystem
needs to do async then you'll have to do the same
timing semantics or copy the default code into
your VFS implementation). The upper layer async
queue logic only gets triggered if the VFS returns
NT_STATUS_MORE_PROCESSING_REQUIRED.

Jeremy.