👍 This design seems pretty elegant and should make it easier for us to implement some of epoll's api, and maybe other things too.

I have a concern on this design. Without signals, it's fine to accidentally add more than one listeners to the event source, but, with them, it's not. Let's look at the refresh_listener function of epoll.

    fn refresh_listener(&mut self, weak_self: Weak<AtomicRefCell<Epoll>>, key: Key) {
        let Some(entry) = self.monitoring.get_mut(&key) else {
            return;
        };

        // Check what state we need to listen for this entry.
        // We always listen for closed so we know when to stop monitoring the entry.
        let listen = entry.get_listener_state().union(FileState::CLOSED);
        let filter = StateListenerFilter::Always;

        // Set up a callback so we get informed when the file changes.
        let file = key.file().clone();
        let handle =
            file.borrow_mut()
                .add_listener(listen, filter, move |state, changed, cb_queue| {
                    if let Some(epoll) = weak_self.upgrade() {
                        epoll
                            .borrow_mut()
                            .notify_entry(&key, state, changed, cb_queue);
                    }
                });
        entry.set_listener_handle(Some(handle));
    }

This seems to me that I can call refresh_listener as many times as I want and the number of listeners added is the same as the number of times I call. Without signals, it's fine because you will just get excessive notifications, but with signals, you will be too many signals.

Can you make sure that all the listeners of all the event sources actually call add_listener only once? If not, I think we will probably need a new design.

Without signals, it's fine because you will just get excessive notifications, but with signals, you will be too many signals.

Each time refresh_listener is called, it adds a new listener and removes the old listener. When the handle returned by add_listener is dropped, the listener for that handle is removed. So when entry.set_listener_handle(Some(handle)) is called, it replaces the old handle with the new handle, dropping the old handle and removing the old listener. So it should only receive a single notification, even if you call refresh_listener many times on the same key/entry.

I'm not completely on clear on the concern about multiple listeners receiving the same signal. And is the original "INPUT_BUFFER_PARITY" any different, I think you'd also see that state flag change on all listeners as well?

Each time refresh_listener is called, it adds a new listener and removes the old listener. When the handle returned by add_listener is dropped, the listener for that handle is removed. So when entry.set_listener_handle(Some(handle)) is called, it replaces the old handle with the new handle, dropping the old handle and removing the old listener. So it should only receive a single notification, even if you call refresh_listener many times on the same key/entry.

Alright, got it. Thanks.

I'm not completely on clear on the concern about multiple listeners receiving the same signal. And is the original "INPUT_BUFFER_PARITY" any different, I think you'd also see that state flag change on all listeners as well?

Yeah, it's probably not different. So, never mind :)

I think this PR is great. I will do the edged-triggered epoll after this PR is merged.