Add `is_disconnected()` to `std::sync::mpsc` and `std::sync::mpmc`

[LevitatingBusinessMan]

Proposal

Problem statement

The mpsc and mpmc channel API's do not support checking if the endpoint is connected, without first attempting to send or receive a message.

Motivating examples or use cases

Imagine you have a thread, which runs the state for a QUIC connection.
Any incoming data this thread produces, is send over a channel to a consumer.

If the consumer panics or otherwise drops the Receiver, the thread will unknowingly do work keeping the connection alive.
Only will it learn that the channel has been disconnected, when it tries to send data.

Instead, it could check tx.is_connected() in its main loop to determine if it's Receiver has disconnected.
If so, it can terminate its own connection immediately.

Solution sketch

std::sync::mpmc::Sender<T>::is_disconnected(&self) -> bool
std::sync::mpmc::Receiver<T>::is_disconnected(&self) -> bool

std::sync::mpsc::Sender<T>::is_disconnected(&self) -> bool
std::sync::mpsc::Receiver<T>::is_disconnected(&self) -> bool

The mpsc methods would be behind feature gate mpsc_is_disconnected.
The mpmc methods can be added to the existing mpmc_channel feature gate.

The mpmc implementation may be as simple as:

    pub fn is_disconnected(&self) -> bool {
        match &self.flavor {
            ReceiverFlavor::Array(chan) => chan.is_disconnected(),
            ReceiverFlavor::List(chan) => chan.is_disconnected(),
            ReceiverFlavor::Zero(chan) => chan.is_disconnected(),
        }
    }

The is_disconnected method for the Zero flavor may be implemented by reading its inner is_disconnected field.
The is_diconnected method is already implemented for the other two flavors.

Alternatives

As an alternative, either end of the channel may hold a Weak reference to the other. If this reference fails to upgrade, the other endpoint must have dropped.

Links and related work

PR: rust-lang/rust#153170

How to tell if a channel’s sender still has a valid receiver?

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[taiki-e]

Using this to check whether “it's already dead” is fine, but using it to check whether “it's sendable” is unsuitable due to race condition. (Although when the channel becomes reconnectable, the former also becomes complicated.) At least without proper documentation for it, I don't feel we should add such an API.

FYI, neither golang nor crossbeam has this due to such concerns at this time. See also golang/go#30906, crossbeam-rs/crossbeam#236, crossbeam-rs/crossbeam#497, etc.

[kpreid]

Precedent: flume has such a method (and does not have "reconnectable").

[BurntSushi]

My take is that a method like this is very likely to be used incorrectly and in a way that leads to undesirable race conditions. I think if we were going to add a method like this, then we'd need a more compelling motivation than what's stated so far.

[cuviper]

I think this is similar in spirit to the as-yet-unstable Arc::is_unique, or its even racier weak/strong_count methods.

[LevitatingBusinessMan]

Could we document it in such a way to prevent people from using it in the racing form?

// this is obviously bad
if !tx.is_disconnected() {
    tx.send()
}

It should be clear that it's only useful to check if the channel is dead, checking if it's alive isn't useful. That's why I chose the name is_disconnected().

As for motivation, I think my connection upkeep example is clear. If you have a thread that does any kind of work, knowing if the other side of a channel is dead allows you to stop early.

My practical use-case is the one I mentioned. I have an implementation of a QUIC server that makes a lot of use of channels and threads. Basically any of these threads can stop early if any of their associated channels has quit, so that the connection may be closed gracefully and quickly. The alternative is waiting around until the channels are used (which may be never).

[LevitatingBusinessMan]

For the record, the current documentation in the PR looks like

/// Returns `true` if the channel is disconnected.
///
/// # Examples
///
/// ```
/// #![feature(mpsc_is_disconnected)]
///
/// use std::sync::mpsc::channel;
///
/// let (tx, rx) = channel::<i32>();
/// assert!(!tx.is_disconnected());
/// drop(rx);
/// assert!(tx.is_disconnected());
/// ```

Edit: I added a note to the documentation regarding the race condition.

/// Note that a return value of `false` does not guarantee the channel will
/// remain connected. The channel may be disconnected immediately after this method
/// returns, so a subsequent [`Sender::send`] may still fail with [`SendError`].

See also the PR.

[quaternic]

I think this method should exist, since it seems unnecessary to force the sender to create the next value to send before it can discover that the receiver is no longer interested.

Even a successful send doesn't guarantee that the value is received (unless it's a 0-capacity channel), since the receiver could hang up immediately afterwards.

Suppose there was a "send multiple" -operation. Presumably sending 0 items could error if the channel has disconnected. That would be a reasonable workaround if it existed, but an explicit is_disconnected is still clearer.

[programmerjake]

a send-multiple and a receive-multiple allows you to easily get a (slightly inefficient) semaphore too: just make a channel with item type () or something.

[kpreid]

I have a use case which does not relate to cancelling work or have a race condition. Suppose there is some source of rare events which are of interest to many recipients, and the recipients come and go. Logically, it is something like a Vec<dyn SenderTrait<Event>>. (Other factors mean that a broadcast channel type is not suitable, even though it would be more efficient.)

In this case, if recipients come and go more often than messages are sent, it is desirable to be able to clean up defunct senders, without sending, to avoid unbounded allocation in the Vec. This can be done with is_disconnected(). (It can also be done by sending a dummy “ping” message, but that requires the receiver’s cooperation to define such a message, and unnecessarily wakes up all receivers.)

Practically, I now use flume here, but I mention this as an example of why one might want is_disconnected() without involving any race conditions at all. (Also, the design I use for what I’m calling SenderTrait is in fact one where a “send_multiple()”, as mentioned above, is the only method, so if there was such a thing instead of is_disconnected(), that would be even better.)

[nia-e]

Per discussion in today's @rust-lang/libs-api meeting, we're okay with such a method being added with the condition that documentation is clear about the possible raciness. Especially there were worries about how this could interact with any future change proposal making the stdlib channels reconnectable, but as long as the documentation is clear on the matter, the possible usecases seem worth it. It may also be worth adding a clippy lint against if !tx.is_disconnected() { tx.send() }-style constructions.

[LevitatingBusinessMan]

What is the next step? Do I label the PR S-waiting-on-review?