update linkerd2-cache and linkerd2-lock to std::future#490
update linkerd2-cache and linkerd2-lock to std::future#490hawkw merged 15 commits intomaster-tokio-0.2from
Conversation
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
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 <[email protected]>
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 <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
|
@hawkw looks like Cargo.lock is out of date? |
| tracing = "0.1.9" | ||
| tracing-futures = "0.1" | ||
| webpki = "0.21" | ||
| webpki = "=0.21.0" |
There was a problem hiding this comment.
BTW, i published an updated version of our fork a while ago https://github.com/linkerd/webpki/tree/cert-dns-names-0.21
|
@hawkw Would we still need the specialized |
olix0r
left a comment
olix0r
left a comment
There was a problem hiding this comment.
I'm OK with this merging when it's green. I think, ideally, we ought to get rid of our lock implementation.... but that's not a blocker.
If we wanted to use Tokio's |
|
@hawkw I'd have to check to confirm, but I believe we wrap all of these with |
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 <[email protected]>
kleimkuhler
left a comment
kleimkuhler
left a comment
There was a problem hiding this comment.
Looks like Cargo.lock still needs to be updated but changes look good!
tokio-rs/tokio#2455 merged upstream, so we could definitely do this. Also, we can now remove all the |
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
olix0r
left a comment
olix0r
left a comment
There was a problem hiding this comment.
lgtm, modulo the unrelated comment change
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
3 participants
This branch updates the
linkerd2-cachecrate (andlinkerd2-lock,which it relies on), to use
std::future.Unlike previous PRs, the
linkerd2-lockupdate is a more substantialrewrite, because upstream API changes made the previous implementation
no longer possible. In particular,
tokio::sync::Mutexdoes not providea
poll_acquiremethod the way thattokio_sync::Lockdid in Tokio0.1. The removal of
poll_acquireis largely due to the rewrite ofTokio's synchronization primitives to use an intrusive linked list-based
semaphore (tokio-rs/tokio#2325), which requires waiters to be pinned to
ensure safety of the intrusive list. Allowing permits to be acquired
only from a future ensures correct pinning of waiters.
Therefore, I've implemented a new
Lockfor Linkerd which uses a TokioSemaphorewith 1 permit to ensure exclusive access. TheLockowns aboxed instance of the future returned by
Semaphore::acquire, anddrives it in
poll_acquire. This allows adapting the poll-based Towerinterface with the futures-only, pinned interface.