[PATCH]: Windows BRL Try 2

[Zack Kirsch]

I think we're in complete agreement. I was hoping we wouldn't have to do
the "is_lockingX" trick too; I just didn't know why that was a special
case for only lockingX. :)

This isn't top of my list, but it's definitely a way forward for a more
performant BRL path (for us).

Thanks for the input,
Zack

>> -----Original Message-----
>> From: Jeremy Allison [mailto:jra at samba.org]
>> Sent: Wednesday, February 18, 2009 3:59 PM
>> To: Zack Kirsch
>> Cc: Jeremy Allison; samba-technical at samba.org
>> Subject: Re: [PATCH]: Windows BRL Try 2
>> 
>> 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.