Add tokio02-style mpsc sender

[MikailBag]

Motivation

Some users want to have poll-based API for mpsc channels.

Solution

Add some amount of unsafe.

[MikailBag]

This boxing can be avoided when type_alias_impl_trait finally lands.

[hawkw]

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.

[MikailBag]

It seems that cancellation token tests are just ignored currently.

[Darksonn]

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.

[MikailBag]

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.

[coolreader18]

I think the CI failure is due to tokio-util not explicitly depending on the tokio/sync feature. Also, I have a use case for this feature, in wrapping a Sender in an AsyncWrite.

[MikailBag]

fmt job fails on code that was not changed by this PR.
It seems that rustfmt somehow changed its behavior.

[taiki-e]

Format issue was fixed by #3160. It can be fixed by merging master.

[coolreader18]

I might have misunderstood, but I think making T not require 'static doesn't necessarily mean adding another 'a lifetime parameter. Cause the permit is supposed to be a self reference, right? So what lifetime would make sense for 'a other than 'static?

[MikailBag]

Well, I have to use some lifetime for Permit<'_, T>.
If I use 'static, it rules out all non-'static types.
Of course, for owned message types 'a should be selected as 'static.

Do you have any ideas on how to make it easier to use?

[coolreader18]

Oh, I see... the variance of Permit requires that T: 'a, and 'a can't be 'static if T: !'static. That is really tricky, I don't think I have an easy solution.

[Darksonn]

I don't think we can get around that without implementing it in Tokio proper.

[MikailBag]

Actually, it seems that we can have a generic wrapper that can poll-ify arbitrary async fn. I'll check if I'm right.

[MikailBag]

Committed new, generic pollifier.

[coolreader18]

Is there any update on this?

[MikailBag]

AFAIK this PR needs some review

[Darksonn]

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.

[Darksonn]

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.