[PATCH]: Windows BRL Try 2

[Volker Lendecke]

On Wed, Feb 18, 2009 at 03:58:57PM -0800, Jeremy Allison wrote:
> 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.

Have you looked at the code I've added for external named
pipes? Here I have a np_read_send/recv pair which is always
used. For the internal pipes I've added an immediate trigger
to the event loop. This way we keep the code simple: The
upper layers are *always* async, even if we get the lock
immediately. I haven't really benchmarked that yet (named
pipes per definition are not performance-sensitive), but my
rough guess is that the additional malloc's don't really
hurt too badly. And if they do, we need to make the
immediate trigger and the async req setup faster by possibly
using some talloc_pool tricks again.

But for the requests that *might* be async, I would really
like to make the normal code paths cope with an async call
in the VFS.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20090219/5179c547/attachment.bin