-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Conversation
87901fe
to
c5f78cb
Compare
I had used |
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, 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.
Oh, lol, I wrote an almost word-for-word identical version of this a couple days ago but didn't open a PR. LGTM! 👍 |
It might also be nice to have a similar API for |
Someone did ask for such an api on |
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>
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>
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>
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>
This implements the suggestion in @hawkw's comment on #1998.