-
Notifications
You must be signed in to change notification settings - Fork 635
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
Support shared futures on no_std #2868
Conversation
Thanks for the PR. I would prefer not to use spinlock by default around operations that would involve allocations even if it is no_std-only. That said, it might be fine if this is an optional feature and spinlock is used only when std is disabled and the feature is explicitly enabled. |
I moved the spinlock behind an optional |
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.
Thanks!
Currently,
Shared
futures are only available when thestd
feature is enabled because they usestd::sync::Mutex
internally. This PR changes this so thatShared
futures will fall back to using a spinlock whenstd
is not enabled.Alternatively,
Shared
could be changed to be generic over a mutex trait (e.g.lock_api::RawMutex
, though it isn't implemented forstd::sync::Mutex
) to allow arbitrary user implementations.