[poll] Your opinions about unbuffered channel

[frostyplanet]

Unbuffered channel is popular in Golang developers, but I want to know how much do you need it in Rust?

Since the limitation of cancellation in Rust Future, there are difficulties in implementing reliable one, as discussed in #11

[SaltyKitkat]

I use zero-bounded channel as a reusable one-shot channel in my project. Let's say we have to tasks: A and B. B wants to do a "remote" function call, which is implemented by sending a message to A using a bounded channel, and getting something back from A using an one-shot channel. But we have to re-create the channel when getting things from A. If we have a zero-bounded channel, we can use it to get things from A, since B is always blocked on recv() when A is sending.

[frostyplanet]

I am thinking about adding non-reusable oneshot channel that uses existing sender/receiver types, which are cheap enough to create and drop, in "spsc" category. Its internal is just one Arc.
because the reusable concept (requires Clone) makes it not "sp" but "mp",

The concept of "unbuffered channel" sounds heavier than a normal buffering channel, because after the sender sends a message in it, has to wait for the Ack from the receiver side, which introduces another park() in threading context", or pending for re-schedule in async context, and the receiver is likely parked due to waiting, which makes it much slower (> 2x ) than a size 1 channel .

[SaltyKitkat]

In my case, when sender is sending, the receiver is always ready and waiting to receive the message. And I se it as a spsc. So it's fine for me. mpmc unbuffered seems terrible, as you said.
Another problem is that when using one-shot channel, I have to send the receiver to A every time. While with an 0 sized channel, I can register the sender in A once, when creating B.
But it's always good to have a cheap one-shot channel ;)

[frostyplanet]

I think the scenario you described, a normal buffering channel will do well, not slower than an unbuffered channel, if the channel structure is reused to avoid allocation cost.
There's some unclear definition of behavior for the rendezvous/handsake concept. let's assume there's only one core async runtime, only one Future can be executed at one time. The receiver future blocked for a message. As kanal implementation, there's no buffering in the channel, but instead the buffer is in receiver. The Sender see the receiver and put a message in it. Some might say the receiver is "ready" so that sender can return Ok(()), but in more strict point of view. The receiver's future is just pending, there's no guarantee it will retrieve the message from it or will be cancel with timeout. So I think the sender should pending again, wait until the receive future actually poll Ready with message, the sender should waked up and return Ready(Ok(())).

[SaltyKitkat]

Yes that makes a lot of sense. I never realize that. Thanks for the detailed explanation.