-
Notifications
You must be signed in to change notification settings - Fork 32
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
Replace some async blocks with manual futures #34
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.
LGTM
src/lib.rs
Outdated
pub use barrier::{Barrier, BarrierWaitResult}; | ||
pub use mutex::{Mutex, MutexGuard, MutexGuardArc}; | ||
pub use mutex::{Lock, LockArc, Mutex, MutexGuard, MutexGuardArc}; | ||
pub use once_cell::OnceCell; | ||
pub use rwlock::{RwLock, RwLockReadGuard, RwLockUpgradableReadGuard, RwLockWriteGuard}; | ||
pub use semaphore::{Semaphore, SemaphoreGuard, SemaphoreGuardArc}; | ||
pub use semaphore::{Acquire, AcquireArc, Semaphore, SemaphoreGuard, SemaphoreGuardArc}; |
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.
Why are the futures from rwlock and barrier not exported?
That said, exporting everything might make the documentation less readable... (FYI, tokio
has modules for named futures. futures
exposes each of the sub-modules or gives a verbose name.)
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.
I added a futures
module that contains all of the exported named futures.
The goal of this PR is to resolve #4 by adding manually-implemented futures to
Mutex
,RwLock
,Barrier
andSemaphore
, similar to smol-rs/async-channel#33. This aim of this PR is to improve semantics for whenpoll
is the only means available to poll a future. The main downside is that is replaces the elegantasync
blocks with some more garish manual futures, but I tried to keep the semantics and ordering of logic the same throughout.I avoided adding implementations for
OnceCell
, since with the closures and self-referential ideas it's not possible to implement without either a significant amount of hard-to-checkunsafe
code or overextensive heap allocation.Closes #4
Closes #5