Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrading v4 to v5 panic: Listener was never inserted into the list #124

Open
jbr opened this issue Mar 23, 2024 · 6 comments
Open

Upgrading v4 to v5 panic: Listener was never inserted into the list #124

jbr opened this issue Mar 23, 2024 · 6 comments

Comments

@jbr
Copy link
Contributor

jbr commented Mar 23, 2024

I'm unsure if I'm holding the new interface wrong somehow or if I've encountered a bug.

Given this diff that attempts to track the event-listener interface changes, I'm encountering a deterministic panic like:

event-listener-5.2.0/src/lib.rs:1251:36:
listener was never inserted into the list

and as far as I can tell the code reduces to

let n = AtomicUsize::from(1);
let event = Event::new();
let mut listener = event.listen();
loop {
    if 0 == n.load(Ordering::SeqCst) {
        return Poll::Ready(());
    };
    ready!(Pin::new(&mut listener).poll(cx));
}

Do I need to replace the listener every time I poll it? Am I holding this wrong? Is this a bug?

If I'm using it wrong I'll happily contribute documentation to help others avoid this error

@notgull
Copy link
Member

notgull commented Mar 24, 2024

It seems you are using the future like this:

let mut listener = event.listen();
loop {
    if 0 == n.load(Ordering::SeqCst) {
        return Poll::Ready(());
    };
    ready!(Pin::new(&mut listener).poll(cx));
} 

It should be used like this:

let mut listener = None;
loop {
    if 0 == n.load(Ordering::SeqCst) {
        return Poll::Ready(());
    };
    if let Some(listener) = listener.as_mut() {
        ready!(Pin::new(&mut listener).poll(cx));
        listener = None;
    } else {
        listener = Some(event.listen());
    }
}

Polling the EventListener after it has returned Ready will panic, and further polls should use a completely new EventListener instead.

The v4 API kept track of this state inside of the EventListener, but this caused confusion and was removed in v5.

@notgull
Copy link
Member

notgull commented Mar 24, 2024

If you think this could be made clearer in documentation I would accept a PR.

@jbr
Copy link
Contributor Author

jbr commented Mar 24, 2024

Would it make sense to just always return ready once it has ever been ready instead of panicking? That seems a lot easier to document and explain.

@notgull
Copy link
Member

notgull commented Mar 24, 2024

Rust's documentation seems to imply that a panic is the preferred option in this case.

@jbr
Copy link
Contributor Author

jbr commented Mar 24, 2024

It looks like EventListener holds an InnerListener that contains a reference to the Event. Would it work to have a configurable option that allows the listener to reregister itself on completion? It feels awkward to require user code to match Pin::new(&mut listener).poll(cx) { Poll::Ready(()) => { *listener = event.listen(); ... }, ... }

jbr added a commit to jbr/stopper that referenced this issue Mar 24, 2024
…le wakes

This resolves a potential bug that has not yet been observed with Stopper. It would only be encountered if the Event were notified before the atomic boolean was stored. Although the usage of atomics should make guard against this, the future logic still should take into consideration the possibility that the future was erroneously woken.

I misunderstood the contract for EventListener, which turns out to be that each EventListener is only good for one wake, after which it needs to be replaced with a new listener. I thought that repeatedly polling the listener would repeatedly wake it on Event notification.

refs: smol-rs/event-listener#124
jbr added a commit to jbr/stopper that referenced this issue Mar 24, 2024
…le wakes

This resolves a potential bug that has not yet been observed with Stopper. It would only be encountered if the Event were notified before the atomic boolean was stored. Although the usage of atomics should make guard against this, the future logic still should take into consideration the possibility that the future was erroneously woken.

I misunderstood the contract for EventListener, which turns out to be that each EventListener is only good for one wake, after which it needs to be replaced with a new listener. I thought that repeatedly polling the listener would repeatedly wake it on Event notification.

refs: smol-rs/event-listener#124
jbr added a commit to jbr/stopper that referenced this issue Mar 24, 2024
…le wakes

This resolves a potential bug that has not yet been observed with Stopper. It would only be encountered if the Event were notified before the atomic boolean was stored. Although the usage of atomics should make guard against this, the future logic still should take into consideration the possibility that the future was erroneously woken.

I misunderstood the contract for EventListener, which turns out to be that each EventListener is only good for one wake, after which it needs to be replaced with a new listener. I thought that repeatedly polling the listener would repeatedly wake it on Event notification.

refs: smol-rs/event-listener#124
@notgull
Copy link
Member

notgull commented Mar 25, 2024

It's a bad idea to have the EventListener automatically insert itself into the list. Generally, the flow should be:

  • Check your condition.
  • Register the listener into the list.
  • Check your condition, ideally with stronger ordering.
  • Wait on the listener.

If you register the listener into the list without actively polling an event, it can lead to strange behavior. E.g. your future received a notification meant for another task

notgull added a commit that referenced this issue Mar 26, 2024
This commit makes the panic message for a listener that's not inserted
into the linked list much clearer. The goal is to convey to the user
that they may be `poll`ing the listener after it has completed.

This commit also fixes some new Clippy lints.

cc #124

Signed-off-by: John Nunley <dev@notgull.net>
notgull added a commit that referenced this issue Mar 28, 2024
This commit makes the panic message for a listener that's not inserted
into the linked list much clearer. The goal is to convey to the user
that they may be `poll`ing the listener after it has completed.

This commit also fixes some new Clippy lints.

cc #124

Signed-off-by: John Nunley <dev@notgull.net>
notgull added a commit that referenced this issue Mar 28, 2024
This commit makes the panic message for a listener that's not inserted
into the linked list much clearer. The goal is to convey to the user
that they may be `poll`ing the listener after it has completed.

This commit also fixes some new Clippy lints.

cc #124

Signed-off-by: John Nunley <dev@notgull.net>
notgull added a commit that referenced this issue Apr 11, 2024
This commit makes the panic message for a listener that's not inserted
into the linked list much clearer. The goal is to convey to the user
that they may be `poll`ing the listener after it has completed.

This commit also fixes some new Clippy lints.

cc #124

Signed-off-by: John Nunley <dev@notgull.net>
notgull added a commit that referenced this issue May 4, 2024
This commit makes the panic message for a listener that's not inserted
into the linked list much clearer. The goal is to convey to the user
that they may be `poll`ing the listener after it has completed.

This commit also fixes some new Clippy lints.

cc #124

Signed-off-by: John Nunley <dev@notgull.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants