lkml.org 
[lkml]   [2008]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [fuse-devel] [PATCHSET] FUSE: extend FUSE to support more operations
From
Date
Hi Tejun,

On Mon, 17 Nov 2008, Tejun Heo wrote:
> Hello, Miklos.
>
> I tried to implement poll as you suggested but it doesn't work because
> poll actually is synchronous. Please consider the following scenario.
> A file system implements a file which supports poll and other file
> operations and there's a single threaded client which does the
> following.

Hmm, I do see your point.

> 1. open the file
> 2. do polling (timeout == 0) poll on the fd
> 3-1. if POLLIN, consume data and goto #2
> 3-2. if ! POLLIN, do a ioctl (or whatever) on the fd and goto #2
>
> For a client with single stream of syscalls (single threaded), it's
> generally guaranteed that the attempt to consume data is successful
> after POLLIN unless the fd dies inbetween. I don't think this is
> something guaranteed in POSIX but for most in-kernel poll
> implementations, this holds and I've seen good amount of code
> depending on it.
>
> To satisfy the above assumption, if ->poll is always asynchronous,
> FUSE has to cache revents from previous ->poll attempts and clear it
> when something which could have consumed data has occurred.
> Unfortunately, in the above case, FUSE has no idea what constitutes
> "consume data" but, double unfortunately, it can't take big hammer
> approach (clearing on any access) either, because intervening non-data
> consuming call like 3-2 above would mean that poll() will never
> succeed.
>
> Because data availability should be determined atomically && only the
> filesystem knows when or how data availability changes, revents return
> from ->poll() must be synchronous.
>
> We can still use req -> reply approach where there's a flag telling
> the FUSE server whether the request is synchronous or not but at that
> point it seems just obfuscating to me.
>
> So, ->poll() needs to be the combination of synchronous data
> availability check + asynchronous notification which can be spurious
> to implement the required semantics and I think the original interface
> was much more natural for such functionality.

OK, lets do it with the original interface. There's still room for
optimization, though, because the _normal_ operation of poll() is
absolutely asynchronous. I think the 'flags' field in poll_in should
be adequate to make the interface extensible in the future.

Thanks,
Miklos


\
 
 \ /
  Last update: 2008-11-17 11:19    [from the cache]
©2003-2011 Jasper Spaans