-
Notifications
You must be signed in to change notification settings - Fork 32
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
Comments
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 The v4 API kept track of this state inside of the |
If you think this could be made clearer in documentation I would accept a PR. |
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. |
Rust's documentation seems to imply that a panic is the preferred option in this case. |
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 |
…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
…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
…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
It's a bad idea to have the
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 |
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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:
and as far as I can tell the code reduces to
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
The text was updated successfully, but these errors were encountered: