Add force_send method to channel Sender#1135
Add force_send method to channel Sender#1135bergkvist wants to merge 4 commits intocrossbeam-rs:masterfrom
Conversation
crossbeam-channel/src/channel.rs
Outdated
| /// the channel is full. The returned error contains the original message. | ||
| /// | ||
| /// If called on a zero-capacity channel, this method will send the message only if there | ||
| /// happens to be a receive operation on the other side of the channel at the same time. |
There was a problem hiding this comment.
It's not clear from the description what would happen if there is no receive operation. Would the call fail (despite what the start of the comment says)? Would the data be returned to the caller?
|
The "lossy channel" proposal is about removal the oldest element rather than the latest:
Removing the latest element makes it impossible to force send multiple messages unless the reader reads a message at the right time. That's very limiting and unreliable. The "force" is one element deep. Figuratively speaking, users expect a bulldozer, and you give them a chisel. |
taiki-e
left a comment
There was a problem hiding this comment.
Thanks for the PR. I would prefer that force_push in crossbeam_channel have the same semantics as force_push in crossbeam_queue::ArrayQueue (#789):
let q = crossbeam_queue::ArrayQueue::new(2);
assert_eq!(q.force_push(10), None);
assert_eq!(q.force_push(20), None);
assert_eq!(q.force_push(30), Some(10));As said in #400 (comment), it should be able to be implemented by porting #789.
|
I agree that removing the oldest entry is more desirable than removing the most recent one. I've been putting some more thought into this, and force_send seems to be tricky compared to try_send. Consider the following, a Notice that And here lies the problem, H and T both are atomic usizes, meaning we can ensure atomicity when updating one of them using |
…recent one first Note that this is a very naive implementation of force_send, that works when used within a single thread, but can easily fail when multiple threads/cores are involved.
58b5f01 to
0a63ca1
Compare
I had a cursory look at the implementation in #789 and I couldn't really see what makes this issue different. What mandates an atomic update of both head and tail for a channel when a non-atomic update is acceptable for |
Add a force_push method to the Sender part of a channel.
In particular, this is useful for bounded channels of non-zero size.
Motivation:
Design goals:
Closes #400