Messages in this thread | | | Date | Thu, 13 Nov 2008 23:29:17 +0900 | From | Tejun Heo <> | Subject | Re: [PATCHSET] FUSE: extend FUSE to support more operations |
| |
Miklos Szeredi wrote: > On Thu, 13 Nov 2008, Tejun Heo wrote: >> We don't need POLL_RELEASE > > What happens on timeout? Do we just let userspace continue polling > the file descriptor, and then ignore the notification?
Yeap, spurious notifications don't cause any problems.
>> but we still need POLL-reply (to request) to >> send revents. We can put that into notification too. Hmmm... Yeah, >> that could be simpler for FUSE servers. I'll venture that way. > > Then in fact the notification could just become the reply: > > <- POLL-request (sent with request_send_nowait()) > ... > -> POLL-reply (calls req->end()) > > So there won't even be a need to implement notification (we'll need > that for other things in the future) simplifying things even further. > Even if we want to cancel the request because of a timeout, that could > be done with the existing INTERRUPT request.
poll/select/epoll can poll on massive number of files. I don't think it's wise to have that many outstanding requests. FUSE currently uses linear list to match replies to requests and libfuse will consume one thread per each poll if implemented like other requests. It can be made asynchronous from libfuse tho.
I kind of like the original implementation tho. The f_ops->poll interface is designed to be used like ->poll returning events if available immediately and queue for later notification as necessary. Notification is asynchronous and can be spurious (this actually comes pretty handy for low level implementation). When notified, upper layer queries the same way using ->poll. This is quite convenient for low level implementation as the actual logic of poll can live in ->poll proper while notifications can be scattered around places where events can occur.
Thanks.
-- tejun
| |