Messages in this thread | | | Date | Thu, 13 Nov 2008 20:54:48 +0900 | From | Tejun Heo <> | Subject | Re: [PATCHSET] FUSE: extend FUSE to support more operations |
| |
Hello,
Miklos Szeredi wrote: >> Why do you think using separate poll handle would be better? And do you >> still think the overhead is justifiable? > > Because it would be a change in the semantics of the file handle. > Previously it was just an opaque cookie that the kernel stored for the > filesystem, not making any assumptions about it (like uniqueness). > > OK, we can say that if the filesystems wants to implement poll, it has > to make the file handle unique. Also now the filesystem (or > something) has to deal with races between poll notification and > reuse of the file handle (release/open). > > With a new poll handle we'd have more room to properly deal with these > without overloading the file handle with extra requirements. > > How about this: the poll handle is allocated by the kernel, not by the > filesystem. This guarantees uniqueness, so the filesystem cannot get > this wrong. Releasing the poll handle is still tricky, there could be > various races... only the userspace filesystem knows if it has no > outstanding notificiatons on a poll handle, so the release has to come > after all outstanding notifications have been ack'ed. Something like > this: > > (userspace <- kernel) > > <- POLL-request(pollhandle) (alloc handle) > -> POLL-reply > ... > -> POLL-notification(pollhandle) > <- POLL-ack > ... > <- POLL_RELEASE(pollhandle) > -> POLL_RELEASE-reply (free handle)
Hmm... yeah, allocating handle from kernel should work fine, but I wouldn't worry about race here. We can just use 64 bit and guarantee that any handle won't be reused ever.
Thanks.
-- tejun
| |