Skip to content
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

Closed
NeoLegends opened this issue Dec 3, 2020 · 7 comments
Closed

Poll-style APIs for sync primitives #3209

NeoLegends opened this issue Dec 3, 2020 · 7 comments
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. M-sync Module: tokio/sync

Comments

@NeoLegends
Copy link
Contributor

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 implementing poll_ready.

@NeoLegends NeoLegends added A-tokio Area: The main tokio crate C-feature-request Category: A feature request. labels Dec 3, 2020
@Darksonn Darksonn added the M-sync Module: tokio/sync label Dec 3, 2020
@NeoLegends
Copy link
Contributor Author

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.

@Darksonn
Copy link
Contributor

Darksonn commented Dec 7, 2020

We are working on this for mpsc in #3105. The poll_* functions can in some cases not be added directly on the primitive as the operation requires a !Unpin piece that is stored in the future. It is however possible build a wrapper that includes this piece and has &mut self poll methods rather than the usual &self methods.

@NeoLegends
Copy link
Contributor Author

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

@Darksonn
Copy link
Contributor

Yes. Beyond that, there is also PollSender and the things in tokio_stream::wrappers. Can you update the original issue to mention the things that are missing? E.g. mutex is still missing.

@matklad
Copy link
Contributor

matklad commented Oct 5, 2021

PollSemaphore is missing API to acquire n permits at once. Context: I want to throttle AsyncRead to read at most n bytes per second. The way I want to do that is by creating a semaphore with n permits, which is refilled every second, and I need to use that semaphore from my struct that implements AsyncRead.

@Darksonn
Copy link
Contributor

Darksonn commented Oct 5, 2021

That should be relatively easy to add. If you want to write a PR for it, then go ahead.

@Darksonn
Copy link
Contributor

Darksonn commented Nov 2, 2022

Closed by #5137.

@Darksonn Darksonn closed this as completed Nov 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. M-sync Module: tokio/sync
Projects
None yet
Development

No branches or pull requests

3 participants