Re: [PATCHSET] FUSE: extend FUSE to support more operations

[Tejun Heo <tj@kernel.org>]

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