Closed notgull closed 9 months ago
It appears that this somehow introduces a deadlock into async-lock
. See the test failure here: https://github.com/smol-rs/async-lock/actions/runs/7493609820/job/20509520336
It appears that this somehow introduces a deadlock into
async-lock
. See the test failure here: https://github.com/smol-rs/async-lock/actions/runs/7493609820/job/20509520336
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?
Any progress on this?
None yet. At the moment I'm still trying to replicate the deadlock using only event-listener
.
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?
I would agree with this. Most of the smol crates are already ported to event-listener v4.
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?
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 https://github.com/smol-rs/async-lock/pull/74/commits/1d97f8a8879e069f2438627cad64f7354d5db1e1. I think this should be ready now.
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