[PATCH]: Windows BRL Try 2

[Jeremy Allison]

On Wed, Feb 18, 2009 at 12:33:35PM -0800, Zack Kirsch wrote:
> 
> The issue here is that the decision to do an async lock is done after
> trying a 
> synchronous lock. As the code currently lies, doing an async lock
> depends on the
> return status of the sync lock call.
> 
> I think it would be a cleaner abstraction if we know whether we're okay 
> doing an async lock from the beginning (i.e. when the sync-lock call is
> made.)
> Only paths that absolutely want no async locking would call into 
> BRL_LOCK_WINDOWS_SYNC(), whereas paths that are okay with an async setup
> would
> call into BRL_LOCK_WINDOWS_ASYNC(). LockingX would then call one or the
> other,
> not both.

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.