Messages in this thread | | | Date | Mon, 17 Nov 2008 18:17:28 +0900 | From | Tejun Heo <> | Subject | Re: [PATCHSET] FUSE: extend FUSE to support more operations |
| |
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.
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.
What do you think?
Thanks.
-- tejun
| |