[PATCH]: Windows BRL Try 2

[Zack Kirsch]

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. :)

Zack

>> Ah ok. CC:ing samba-tech. What we should really do
>> is just have one do_lock call that handles both
>> sync and async case depending on the timeout parameter,
>> and push all that logic down under the VFS layer into
>> the default module.
>> 
>> So we change the brl_lock_windows() to take a
>> timeout parameter instead of the bool blocking_lock
>> parameter, and have it return NT_STATUS_MORE_PROCESSING_REQUIRED
>> in the case where the lock is a blocking one,
>> which causes the upper layer to return without
>> sending a reply and save off the current req
>> struct into the retry queue.
>> 
>> The VFS layer then takes care of rescheduling
>> the retry (if needed) and sending any deferred
>> reply.
>> 
>> Does that work for you ?
>> 
>> Jeremy.