[fuse-devel] FUSE poll request--a couple more questions

[Michael A. <ah...@gm...>]

Miklos,

Your response is very helpful.  I am getting close to understanding. BTW, I
have switched email clients to keep html clutter out.

The poll needs to be non-blocking for the client.  If revent=0 and err=0,
does the kernel return to the user or wait for the timer to pop on the poll
wait queue?

I am still puzzled by the FUSE_POLL_SCHEDULE_NOTIFY action.  Is it expected
that I issue a fuse_notify_poll_wakeup immediately after the poll?  Or may
I wait?

As always, thank you for the fuse kernel implementation and for your
kindness in answering my questions.

Best regards,

--Mike Aho


On Wed, Jun 22, 2016 at 5:04 PM, Michael E Aho <me...@us...> wrote:
> Miklos, Sorry on the slow response. I have been on holiday and now am
back.
>
> In part, I don't understand the communication flow between the fuse kernel
> code and the poll messages. I was expecting the timer to pop if I held the
> poll request.

FUSE_POLL is non-blocking, it should return immediately.  It should do
two things:

1) check current events on the open file and return in
fuse_poll_out.revents  (mandatory) ,

2) set up notification in case of a future event (madatory if
FUSE_POLL_SCHEDULE_NOTIFY, otherwise optional).

If FUSE_POLL is received while notification is already active on the
open file, it may merge the two, or it may do two separate
notifications.  That's up to the implementation.

FUSE_POLL does not receive information about the timeout, that's
handled by the kernel.  Currently there's no way to disable a request
for a notification. The kernel will ignore NOTIFY_POLL when the poll
is no longer active.

When a file is released, all notifications may be deleted.  But again
the kernel will just ignore NOTIFY_POLL if sent after the release.

Does that help?

Thanks,
Miklos

-- 
Miklos,