You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If this crate were no_std, it would allow crates like async-lock and async-channel to be used on no_std as well. I envision an API with a default std feature, and without it this crate would not depend on parking (and the wait API would disappear as well).
However, the current version of the code uses a Mutex to lock the linked list containing event listeners. Theoretically, we could replace this with an atomic linked list similar to the one used in concurrent-queue.
This would help smol be able to be used in embedded systems. Any thoughts on this?
The text was updated successfully, but these errors were encountered:
If this crate were
no_std
, it would allow crates likeasync-lock
andasync-channel
to be used onno_std
as well. I envision an API with a defaultstd
feature, and without it this crate would not depend onparking
(and thewait
API would disappear as well).However, the current version of the code uses a
Mutex
to lock the linked list containing event listeners. Theoretically, we could replace this with an atomic linked list similar to the one used inconcurrent-queue
.This would help
smol
be able to be used in embedded systems. Any thoughts on this?The text was updated successfully, but these errors were encountered: