Should Sender::try_send return the message on failure?

[brson]

If we add a synchronous channel it will need to return the message if the queue is full, and it might as well return the message if the channel is closed. Seems useful to be able to retrieve the message in all cases where a send doesn't succeed.

Nominating.

[liigo]

+1

[thestinger]

Here's the API used by rust-core for multiple-producer/multiple-consumer bounded queues:

/// Return a new `BoundedPriorityQueue` instance, holding at most `maximum` elements.
fn new(maximum: uint) -> BoundedPriorityQueue<A>;

/// Pop the largest value from the queue, blocking until the queue is not empty
fn pop(&self) -> A;

/// Pop the largest value from the queue, or return `None` if the queue is empty.
fn try_pop(&self) -> Option<A>;

/// Pop the largest value from the queue, blocking until the queue is not empty or the timeout
/// expires.
fn pop_timeout(&self, reltime: Time) -> Option<A>;

/// Push a value into the queue, blocking until the queue is not full.
fn push(&self, item: A);

/// Push a value into the queue, or return `Some(item)` if the queue is full.
fn try_push(&self, item: A) -> Option<A>;

/// Push a value into the queue, blocking until the queue is not full or the timeout expires. If
/// the timeout expires, return `Some(item)`.
fn push_timeout(&self, item: A, reltime: Time) -> Option<A>;

There's no split in the types or a closed error case though. That's required if there's going to be a limitation of one consumer, but I don't think a micro-optimization belongs in the default channel you reach for.

In my opinion, a multiple-producer/multiple-consumer queue with support for blocking is the most important type as it supports the most functionality. You can swap it out for a less flexible queue with a single consumer and/or single producer limitation if possible but you're not forced to change your design to accommodate a micro-optimization that's not going to be a measurable difference in most cases. You can also switch to a purely non-blocking queue like the disruptor.

The more restricted forms would be included only after they were shown to offer performance improvements. At the moment, the blocking queue in Thread Building Blocks is significantly faster than Rust's channels despite support multiple consumers with fair scheduling and an optional size bound.

[pnkfelix]

Accepted for P-backcompat-libs (though we may or may not decide to actually do it).

[nikomatsakis]

My feeling is that full vs closed are distinct; it makes sense to get back the message if full, but not necessarily closed, since that may not be detectable and even if the message is enqeued, you don't know that the receiver will read it from the port.