Open daxpedda opened 5 months ago
Yes, the inner mechanism for the EventListener
is a Mutex
, which means that dropping a Recv
will temporarily lock the inner Mutex
so it can update its internal state. If this is happening on a single-threaded WASM context, this shouldn't be happening and it's a bug. If it's happening in web workers, it's expected.
One option is to switch Web to event-listener
's lock-free backend, although it's significantly slower.
If this is happening on a single-threaded WASM context, this shouldn't be happening and it's a bug. If it's happening in web workers, it's expected.
No, this happened in multi-threaded Wasm context, but still on the main thread and not in a Web worker. Was it assumed that multi-threaded Wasm means that its always running in a Web worker?
I can't seem to find the code in async-channel
or event-listener
guarding this stuff behind Wasm or atomics, where exactly does this happen?
One option is to switch Web to
event-listener
's lock-free backend, although it's significantly slower.
Dynamic detection would be nice, but that would require depending on wasm-bindgen
.
I can't seem to find the code in
async-channel
orevent-listener
guarding this stuff behind Wasm or atomics, where exactly does this happen?
The web code just uses the normal code, I think.
Dynamic detection would be nice, but that would require depending on
wasm-bindgen
.
Eh, I'd rather just switch into "lock-free" mode on cfg(all(target_arch = "wasm", not(target_os = "wasi")))
.
I encountered this while testing stuff on Wasm (cleaned stacktrace):
Which I think boils down to:
Recv
holdingRecvInner
RecvInner
holdingOption<EventListener>
EventListener
holdingInnerListener
InnerListener
drop implementation callingstd::Inner::remove()
std::Inner::remove()
callingstd::inner::lock()
std::inner::lock()
callingMutex::lock()
I think in this case spinlooping makes sense when running on Wasm? Let me know if this issue should be moved to
event-listener
instead.