Allow users to create Notifier objects when handling requests

[colinmarc]

This is often useful in poll implementations. It also comes into play in #300, because your initialization and setup (when you can call Session::notifier) is often separate from creating the session.

[cberner]

This doesn't seem like the right place to create a Notifier to me. Do you have an example of how you're using it?

[colinmarc]

Sure, for example here: https://github.com/colinmarc/southpaw/blob/main/src/fs.rs#L350-L354

Each open (which results in an async read) gets its own notifier, so I don't have to pass them around everywhere.

[cberner]

I haven't actually used the notification interface myself, but my understanding is that a Notifier is a communication channel that can push messages to the kernel for updates to various inodes, dir entries...etc. Because it's not specific to the inode being opened in open() adding it to the Request seems off to me.

If it was available in Filesystem::init() would that solve your case? Looking at the code again, I'm not sure that Session::notifier() is the right place to add it.

[colinmarc]

If it was available in Filesystem::init() would that solve your case? Looking at the code again, I'm not sure that Session::notifier() is the right place to add it.

I guess so, but I'd just be wrapping it in an Arc and passing it around some more. IMO Notifiers should be cheap, cloneable (they aren't Clone right now) and readily available. And I think the semantics should match FUSE's as closely as possible.

If you'd like to provide a tighter interface, instead, we could create a scoped object, something like

struct PollHandle {
    pub ph: u64
    notifier: Notifier
}

impl PollHandle {
    pub fn notify(self) -> io::Result<()> {
        self.notifier.poll(self.ph)
    }
}

And pass it in instead of ph: u64 to the poll() call.

[cberner]

That does seem better to me. I haven't used notification myself, but as I understand it there are two distinct use cases:

1. inode and directory cache management. For this case the current interface seems more or less right to me, because you need a Notifier client that you can hold on to and push notifications to the kernel independent of any requests coming in. Although passing it into init() might be better than retrieving it from Session
2. responding to poll() requests. In this case I agree the current interface isn't ideal. I like your suggestion of passing in a PollHandle that can be notified.

Are there any other cases I'm missing?

The thing I want to avoid is adding a notifier to all requests, because many requests don't need a notifier

[colinmarc]

Updated to add the PollHandle type.

[WilliamVenner]

Hi, I tried using the Notifier from within a FUSE handler (specifically for an unlink request) - trying to send a notification (inval_entry, inval_inode, delete, etc.) causes a deadlock. I wanted to investigate why but unfortunately gdb hangs infinitely as well so I decided to move on. How is the Notifier intended to be used for that use case? My workaround for now is to just have a background thread that dispatches queued up notifications, but it would be nice if I could do that in sync with my actual filesystem ops.