Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upTracking issue for channel selection #27800
Comments
alexcrichton
added
T-libs
B-unstable
labels
Aug 13, 2015
This comment has been minimized.
This comment has been minimized.
|
cc me |
This comment has been minimized.
This comment has been minimized.
|
Is it worth investigating @BurntSushi 's https://github.com/BurntSushi/chan ? |
This comment has been minimized.
This comment has been minimized.
|
I also think @carllerche was supporting the idea of removing channels from the stdlib |
This comment has been minimized.
This comment has been minimized.
|
Note that I'm not advocating removing channels from the standard library (plus they're stable). Removing selection is also probably not an option as it's so closely tied to the implementation details of channels. One of the major points of complexity of the current implementation is that it's all basically 99% lock free (giving us a nice performance boost in theory). I believe @BurntSushi's implementation (please correct me if I'm wrong!) is largely based on mutexes and condition variables. |
This comment has been minimized.
This comment has been minimized.
|
@alexcrichton Correct. I doubt very much that |
This comment has been minimized.
This comment has been minimized.
|
I personally prefer the epoll-like design as implemented in comm. |
This comment has been minimized.
This comment has been minimized.
|
Streams in Eventual are lock free :) There is also stream selection, which is lock free (and definitely is a pain to implement). Re: removing channels from stdlib, as @alexcrichton points out, they are stable. I would not worry about adding select to them. They are good as a starting point. If somebody requires more complex concurrency semantics, they can use a lib. I'm not sure why @alexcrichton thinks that removing select from std is hard though... |
Ms2ger
referenced this issue
Aug 16, 2015
Open
Tracking: Unstable Rust feature gates used by Servo #5286
This comment has been minimized.
This comment has been minimized.
tripped
commented
Aug 20, 2015
|
Just hopping on to mention #12902 as one of the current weaknesses of the macro approach to select!. |
This comment has been minimized.
This comment has been minimized.
softprops
commented
Sep 17, 2015
|
Fwiw, channel selection with golang channels is part of what makes golang concurrency story so alluring to newcomers to go. For a newcomer to a safe concurrent language like rust, needing to mull over which 3rd party concurrency crate is popular this week to pick for actually writing concurrent code feels onerous. Having primatives like channels and channel selection in the std lib make rust more attractive for concurrent applications than alternatives like go and make crates a little more interoperable than resolving conflicting implementation issues betwwen 3rd party options. |
This comment has been minimized.
This comment has been minimized.
@softprops This doesn't address your primary concerns, but FYI, |
This comment has been minimized.
This comment has been minimized.
softprops
commented
Sep 17, 2015
|
@BurntSushi nice! |
canndrew
referenced this issue
Oct 9, 2015
Closed
Enter REPL without needing to bootstrap first. #351
This comment has been minimized.
This comment has been minimized.
|
Correct me if I'm wrong, but doesn't the macro approach also have the drawback that selecting over a dynamic set of channels isn't easily expressible? |
This comment has been minimized.
This comment has been minimized.
szagi3891
commented
May 1, 2016
|
Best to get rid of the macro select. |
This comment has been minimized.
This comment has been minimized.
|
Here's a wacky idea: add support for generically sized tuples and anonymous enums. Then it will be possible to select across an arbitrary number of channels of different types without macros:
|
This comment has been minimized.
This comment has been minimized.
|
Is there anyone still using this API? I don't see any obvious path to stabilization. It would be nice to just remove it. |
This comment has been minimized.
This comment has been minimized.
|
@jdm is this still being used in Servo? |
This comment has been minimized.
This comment has been minimized.
|
grep finds 4 instances of |
This comment has been minimized.
This comment has been minimized.
mattgreen
commented
Nov 4, 2016
•
|
I'd like to remove this from watchexec, but I'm unsure what to move to. One of my crates already streams data to me via a channel, so I hopped onto that bandwagon. I'm usually watching for either control-c or file system inputs at all times, since I have cleanup to do when the user hits control-c. |
This comment has been minimized.
This comment has been minimized.
softprops
commented
Nov 4, 2016
|
I've had only good experiences with https://github.com/BurntSushi/chan |
This comment has been minimized.
This comment has been minimized.
szagi3891
commented
Nov 4, 2016
•
|
@mattgreen : This channel type will be :
The main thread would send in theright time message Message::CtrlC. It makes sense ? |
This comment has been minimized.
This comment has been minimized.
|
Servo's It should be noted though that this back-end is not a real implementation, but rather just a partial workaround for platforms that don't have a "real" inter-process implementation yet. While it was originally created for Windows, most likely Windows will be getting a proper implementation soonish. ( servo/ipc-channel#108 ) Right now the So while this back-end might continue to be useful during bring-up of new platforms (depending on whether Servo keeps the option of running in a single process), it's not exactly a first-class citizen I'd say. |
This comment has been minimized.
This comment has been minimized.
|
I'd like to point out that https://github.com/BurntSushi/chan -- which is being touted as a replacement for This might seem convenient for some use cases; but I'm not convinced it's a real win over just wrapping the receiver in a More importantly though, for the vast majority of use cases, sharing the receiver is actually not desirable: rather, it often indicates bugs -- and thus not rejecting this by default is indeed more error prone! (Not even considering implementation overhead for something that's not needed at all in most cases...) |
This comment has been minimized.
This comment has been minimized.
|
@antrik Please see the README for
There are a number of reasons why it doesn't necessarily replace |
This comment has been minimized.
This comment has been minimized.
|
@BurntSushi as long as there is a general understanding that |
This comment has been minimized.
This comment has been minimized.
|
I’m in favor of deleting eventually, but since that part of the code isn’t being actively worked on there isn’t much to gain by deleting sooner rather than later. We can keep it with a deprecation warning for a few release cycles, just in case there are users not covered by Crater to leave them some more time to migrate. (This migration took a while to land in Servo.) I my opinion #54228 can help figure out if we want to keep delaying even the deprecation warning like we did so far. |
SimonSapin
added a commit
to SimonSapin/thread_isolated
that referenced
this issue
Sep 16, 2018
SimonSapin
added a commit
to SimonSapin/thread_isolated
that referenced
this issue
Sep 16, 2018
This was referenced Sep 16, 2018
This comment has been minimized.
This comment has been minimized.
|
Crater has found three regressions. One spurious, one that I submitted a PR to fix, and one in a benchmark measuring specifically the performance of the So let’s formally propose:
@rfcbot fcp close |
This comment has been minimized.
This comment has been minimized.
rfcbot
commented
Sep 16, 2018
•
|
Team member @SimonSapin has proposed to close this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
disposition-close
labels
Sep 16, 2018
This comment has been minimized.
This comment has been minimized.
rfcbot
commented
Sep 19, 2018
|
|
rfcbot
added
final-comment-period
and removed
proposed-final-comment-period
labels
Sep 19, 2018
This comment has been minimized.
This comment has been minimized.
rfcbot
commented
Sep 29, 2018
|
The final comment period, with a disposition to close, as per the review above, is now complete. |
rfcbot
added
finished-final-comment-period
and removed
final-comment-period
labels
Sep 29, 2018
This comment has been minimized.
This comment has been minimized.
|
Next is landing a deprecation warning. |
Mark-Simulacrum
added a commit
to Mark-Simulacrum/rust
that referenced
this issue
Nov 9, 2018
This comment has been minimized.
This comment has been minimized.
|
Triage: this unstable feature was deprecated in 1.32, so it is fine to remove any time. |
This comment has been minimized.
This comment has been minimized.
|
I published a blog post titled Proposal: New channels for Rust's standard library discussing what to do with channels in the standard library. How should we proceed about resolving this issue? Bug #39364 is still present, which @stepancheg attempted to fix in PR #42883 but got stuck waiting on removal of Another option is to switch the whole implementation to https://github.com/stjepang/new-channel. As a bonus, we get performance improvements, Some people have suggested we just deprecate the whole Finally, the last option is to write a RFC for |
This comment has been minimized.
This comment has been minimized.
|
Oh I didn’t realize there was already work blocked on the removal of selection. If you want to send a removal PR feel free to ping me for review. We’re already good to go process-wise. Replacing the internals of |
This comment has been minimized.
This comment has been minimized.
|
@stepancheg Would you be interested in giving PR #42883 another shot and removing selection along the way? For followers of this thread, here's the the last status report on the bug fix. |
This comment has been minimized.
This comment has been minimized.
theronic
commented
Mar 12, 2019
|
What's the succession story for waiting on two channels and taking from the first one that yields a message? |
This comment has been minimized.
This comment has been minimized.
|
Consider using another library such as https://crates.io/crates/crossbeam-channel |
This comment has been minimized.
This comment has been minimized.
havelund
commented
Apr 1, 2019
|
How can one have channels and no selection between channels in the core language. |
This comment has been minimized.
This comment has been minimized.
|
Channels are not in the core language; they are in the standard library. |
This comment has been minimized.
This comment has been minimized.
havelund
commented
Apr 1, 2019
|
Sure, but still: being able to select which channel to read from seems to be a fundamental feature that should follow a message passing paradigm based on channels. I tried using mutexes and that was a disaster since they are not reentrant. |
This comment has been minimized.
This comment has been minimized.
|
@havelund As linked above, use a library: https://crates.io/crates/crossbeam-channel |
This comment has been minimized.
This comment has been minimized.
havelund
commented
Apr 1, 2019
|
Yes thanks. I found it. It seems to work fine. |
alexcrichton commentedAug 13, 2015
This is a tracking issue for the unstable
mpsc_selectfeature in the standard library. Known points: