-
-
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
Add tokio02-style mpsc sender #3105
Conversation
tokio-util/src/sync/mpsc.rs
Outdated
Ready(Permit<'static, T>), | ||
/// We are in process of acquiring a permit | ||
// ALERT: contained future contains self-reference to the sender. | ||
Acquire(Pin<Box<dyn Future<Output = Result<Permit<'static, T>, SendError<()>>>>>), |
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.
This boxing can be avoided when type_alias_impl_trait
finally lands.
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.
Alternatively, if this was implemented in tokio
rather than in tokio-util
, this could just use the internal semaphore implementation's Acquire
future. But, I don't think that's going to ever become public API, so this would need to be in tokio
proper.
@@ -1 +1 @@ | |||
|
|||
mod mpsc; |
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.
It seems that cancellation token tests are just ignored currently.
.github/workflows/ci.yml
Outdated
run: cargo miri test --features rt,rt-multi-thread,sync task | ||
run: | | ||
cargo miri test --features rt,rt-multi-thread,sync task | ||
cargo miri test -p tokio-util 'sync::tests::mpsc' |
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.
This is good, but we should have a miri test that calls is_ready
and clone
while the state is in either Ready
or Acquire
.
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.
Unfortunately it seems that there is no way to poll futures under MIRI.
Of course, I plan to write some less trivial tests but there is no way to verify them in MIRI in the near future.
Co-authored-by: Alice Ryhl <alice@ryhl.io>
I think the CI failure is due to |
|
Format issue was fixed by #3160. It can be fixed by merging master. |
I might have misunderstood, but I think making |
Well, I have to use some lifetime for Do you have any ideas on how to make it easier to use? |
Oh, I see... the variance of Permit requires that |
I don't think we can get around that without implementing it in Tokio proper. |
Actually, it seems that we can have a generic wrapper that can |
Committed new, generic pollifier. |
Is there any update on this? |
AFAIK this PR needs some review |
Just as a status-update, I don't think I will get around to reviewing this until after Tokio 1.0 is released later this month. It involves some serious unsafe code to soundly build a self-referential struct, and there are some things I would have to try out in miri before I am happy with it. |
Closing this, as I have just opened #3490, which implements this without unsafe, while still avoiding allocating for every sent item. The new PR also avoids the lifetime issues that this PR runs into. |
Motivation
Some users want to have
poll
-based API for mpsc channels.Solution
Add some amount of unsafe.