-
Notifications
You must be signed in to change notification settings - Fork 33
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 <[email protected]>
cc smol-rs/event-listener#105 Signed-off-by: John Nunley <[email protected]>
cc smol-rs/event-listener#105 Signed-off-by: John Nunley <[email protected]>
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 <[email protected]>
This commit creates the Listener trait and moves most of EventListener's functionality to that trait. Signed-off-by: John Nunley <[email protected]>
It is instantiated with the listener!() macro. Signed-off-by: John Nunley <[email protected]>
This brings in the try-lock dependency. Signed-off-by: John Nunley <[email protected]>
Signed-off-by: John Nunley <[email protected]>
* Make sure Unpin is implemented for StackListener * Purge the prelude * Remove unused imports from doctests Signed-off-by: John Nunley <[email protected]>
90227db
to
d2a5e11
Compare
cc smol-rs/event-listener#105 Signed-off-by: John Nunley <[email protected]>
cc smol-rs/event-listener#105 Signed-off-by: John Nunley <[email protected]>
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