crossbeam-rs
Introduce disconnection state for channels
(hopefully) much improved pr than https://github.com/crossbeam-rs/crossbeam/pull/959 ....
Currently, crossbeam-channel completely overlaps the channel connected status with rust sender/receiver instance aliveness. While this is uncontroversial and covers most use cases, it prevents advanced channel management.
Namely:
- graceful receiver-initiated shutdown (notify disconnection from receiver to sender and drain all sent-not-received messages): see description of #959
- temporal non-blocking faults (make {receiver,sender} disconnected until new {sender,receiver} is needed): see #750
- off-loaded channel destruction (drop retired receivers outside performance sensitive code-path, which possibly could contain large number of not-received buffered messages while notifying disconnection to senders): see this comment: https://github.com/crossbeam-rs/crossbeam/pull/959#issuecomment-2099543477
While these seem to be unrelated to each other, the underlying problem is the lack of explicit channel disconnection state as described above.
Thereby, this adds the following new methods:
impl Sender {
fn disconnect(&self) -> bool;
fn connect(&self) -> bool;
}
impl Receiver {
fn disconnect(&self) -> bool;
fn connect(&self) -> bool;
}
Fortunately, the implementation is quite simple by decoupling the already-existing disconnected bit (MARK_BIT in tail) into the two: one for ::drop() as was before, one for new ::disconnect(), although this pr touches the heart of the impl unlike #959 (i.e. more intrusive....). Also, the almost all of existing code is already robust enough to introduce the 2 kinds of disconnected status. Come to think of it, {receivers, senders} should be able to cope with disconnected {senders, receivers} at any given moment of time due to drops.
As for performance hit, it should be negligible because there's no additional operation at all. just << 2 instead of << 1 in the performance sensitive code-path. Also, no space increse. There were design considerations.
@taiki-e learning from #1040 , this pr has finished impl for the list flavor, added tests, also documented fully. CI should pass. Could you review this in your free time? Thanks a lot.
@taiki-e friendly ping. although i self-commented some after opening this pr, needing further work, I still think this pr is in some good standing for initial round of code-review. please let me know if i can do anything to moving forward this pr.
@taiki-e hey, another ping from me. just want to let you know I'm very eager to work on this pr.
