-
Notifications
You must be signed in to change notification settings - Fork 29
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
Setup a faster, less footgun-prone API #105
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice work. I believe we're now getting to an API that's simple, sound and at the same time allows to be easily heap-free. 👍
Some nitpicks though. I do realize this is still a draft but thought you'd appreciate early feedback. :)
cc smol-rs/event-listener#105 Signed-off-by: John Nunley <dev@notgull.net>
cc smol-rs/event-listener#105 Signed-off-by: John Nunley <dev@notgull.net>
cc smol-rs/event-listener#105 Signed-off-by: John Nunley <dev@notgull.net>
31a572b
to
30ef2ec
Compare
It appears that this somehow introduces a deadlock into |
Any progress on this? If this is proving difficult and will take time, perhaps we can first have other crates ported to event-handler 4 so folks don't end up depending on multiple versions of event-handler? |
None yet. At the moment I'm still trying to replicate the deadlock using only
I would agree with this. Most of the smol crates are already ported to event-listener v4. |
Cool. I'll see if I can provide a PR for async-broadcast. Any others left? |
Not to my knowledge |
At the moment I think the deadlock is a Miri bug, so I've disabled those tests in smol-rs/async-lock@1d97f8a. I think this should be ready now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alright, let's do it. :)
b1a2273
to
90227db
Compare
Minimal amount of changes to make EventListener a heap-allocated type again. The existence of the EventListener implies that it is already listening; accordingly the new() and listen() methods on EventListener have been removed. cc #104 Signed-off-by: John Nunley <dev@notgull.net>
This commit creates the Listener trait and moves most of EventListener's functionality to that trait. Signed-off-by: John Nunley <dev@notgull.net>
It is instantiated with the listener!() macro. Signed-off-by: John Nunley <dev@notgull.net>
This brings in the try-lock dependency. Signed-off-by: John Nunley <dev@notgull.net>
Signed-off-by: John Nunley <dev@notgull.net>
* Make sure Unpin is implemented for StackListener * Purge the prelude * Remove unused imports from doctests Signed-off-by: John Nunley <dev@notgull.net>
90227db
to
d2a5e11
Compare
cc smol-rs/event-listener#105 Signed-off-by: John Nunley <dev@notgull.net>
cc smol-rs/event-listener#105 Signed-off-by: John Nunley <dev@notgull.net>
This PR sets up a new API that aims to implement #104. It sets up a Listener trait, which is implemented for a heap-based EventListener and a stack-based StackListener. The latter is only able to be instantiated through the "listener!" macro.
While writing this, I realized that this breaks the hand-rolled futures that
async-channel
andasync-lock
use nowadays. For now we can burn that bridge when we get there and just useEventListener
in the hand-rolled futures.Closes #104