-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Poll-style APIs for sync primitives #3209
Comments
A workaround to achieve poll-based functionality now (at the cost of synchronization overhead) is to spawn a task whose only responsibility is to acquire semaphore / mutex permits and send them into a channel. That can then be polled via the regular stream mechanisms. |
We are working on this for mpsc in #3105. The |
For future readers: there is a wrapper for Semaphores with optimized allocation here: https://docs.rs/tokio-util/0.6.4/tokio_util/sync/struct.PollSemaphore.html |
Yes. Beyond that, there is also |
|
That should be relatively easy to add. If you want to write a PR for it, then go ahead. |
Closed by #5137. |
Is your feature request related to a problem? Please describe.
As far as I'm aware the sync primitives (Mutex, Semaphore) do not expose a poll-style API, making them harder to use in hand-implemented futures or, more importantly,
Service::poll_ready
.Describe the solution you'd like
Expose a
.poll()
interface on those primitives that can be used w/o acquiring a future that must be polled first.Describe alternatives you've considered
Currently we get the future, box it up to get nameable types (since they use
async fn
) and then poll those, but that's hacky and less performant.Additional context
Implementing a
tower::Service
that needs access to an async Semaphore do perform it's work. Came across this issue while implementingpoll_ready
.The text was updated successfully, but these errors were encountered: