[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
    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.


     \ /
      Last update: 2008-11-17 11:19    [W:0.021 / U:261.656 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site