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

sync: add owned semaphore permit #2421

Merged
merged 2 commits into from
Apr 20, 2020
Merged

Conversation

Darksonn
Copy link
Contributor

This implements the suggestion in @hawkw's comment on #1998.

@Darksonn Darksonn added C-enhancement Category: A PR with an enhancement or bugfix. A-tokio Area: The main tokio crate M-sync Module: tokio/sync S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 20, 2020
@Darksonn Darksonn requested review from carllerche and hawkw April 20, 2020 18:23
@Darksonn
Copy link
Contributor Author

I had used self: &Arc<Self>, which requires a too-new Rust version. However apparently we can use self: Arc<Self> just fine, so I changed it to that.

Copy link
Member

@carllerche carllerche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I don't love using the owned naming pattern, mostly because I think it is a "new" pattern. However, I don't have a better idea, so I am +1ing it.

@Darksonn Darksonn merged commit 5a54804 into tokio-rs:master Apr 20, 2020
@Darksonn Darksonn deleted the semaphore-owned branch April 20, 2020 20:59
@Darksonn Darksonn added relnotes and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 20, 2020
@hawkw
Copy link
Member

hawkw commented Apr 24, 2020

Oh, lol, I wrote an almost word-for-word identical version of this a couple days ago but didn't open a PR. LGTM! 👍

@hawkw
Copy link
Member

hawkw commented Apr 24, 2020

It might also be nice to have a similar API for Mutex (and maybe even RwLock?) In Linkerd, I ended up just hacking around this which isn't that bad, but it could be nice.

@Darksonn
Copy link
Contributor Author

Someone did ask for such an api on Mutex a few days ago on discord.

hawkw added a commit to linkerd/linkerd2-proxy that referenced this pull request Apr 24, 2020
This branch updates the `concurrency-limit` middleware to std::future.
The new implementation uses the new owned semaphore permit API added in
Tokio 0.2.19 (tokio-rs/tokio#2421). Similarly to #490, the old
implementation could not be directly translated due to `tokio::sync`'s
`Semaphore` losing its `poll`-based API in 0.2.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
hawkw added a commit to linkerd/linkerd2-proxy that referenced this pull request Apr 24, 2020
This branch updates the `concurrency-limit` middleware to std::future.
The new implementation uses the new owned semaphore permit API added in
Tokio 0.2.19 (tokio-rs/tokio#2421). Similarly to #490, the old
implementation could not be directly translated due to `tokio::sync`'s
`Semaphore` losing its `poll`-based API in 0.2.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
hawkw added a commit to linkerd/linkerd2-proxy that referenced this pull request Apr 27, 2020
This branch updates the `concurrency-limit` middleware to std::future.
The new implementation uses the new owned semaphore permit API added in
Tokio 0.2.19 (tokio-rs/tokio#2421). Similarly to #490, the old
implementation could not be directly translated due to `tokio::sync`'s
`Semaphore` losing its `poll`-based API in 0.2.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
@Darksonn Darksonn removed the relnotes label Apr 29, 2020
hawkw added a commit that referenced this pull request Apr 29, 2020
This PR adds a new `OwnedMutexGuard` type and `lock_owned` and
`try_lock_owned` methods for `Arc<Mutex<T>>`.  This is pretty much the
same as the similar APIs added in #2421. 

I've also corrected some existing documentation that incorrectly
implied that the existing `lock` method cloned an internal `Arc` — I
think this may be a holdover from `tokio` 0.1's `Lock` type?

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
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-enhancement Category: A PR with an enhancement or bugfix. M-sync Module: tokio/sync
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants