Yeap, spurious notifications don't cause any problems.
>> but we still need POLL-reply (to request) to
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.
