-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking issue for channel selection #27800
Comments
cc me |
Is it worth investigating @BurntSushi 's https://github.com/BurntSushi/chan ? |
I also think @carllerche was supporting the idea of removing channels from the stdlib |
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. |
@alexcrichton Correct. I doubt very much that |
I personally prefer the epoll-like design as implemented in comm. |
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... |
Just hopping on to mention #12902 as one of the current weaknesses of the macro approach to select!. |
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. |
@softprops This doesn't address your primary concerns, but FYI, |
@BurntSushi nice! |
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? |
Best to get rid of the macro select. |
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:
|
Is there anyone still using this API? I don't see any obvious path to stabilization. It would be nice to just remove it. |
@jdm is this still being used in Servo? |
grep finds 4 instances of |
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. |
I've had only good experiences with https://github.com/BurntSushi/chan |
@mattgreen : This channel type will be :
The main thread would send in theright time message Message::CtrlC. It makes sense ? |
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. |
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...) |
@antrik Please see the README for
There are a number of reasons why it doesn't necessarily replace |
@BurntSushi as long as there is a general understanding that |
Next is landing a deprecation warning. |
…apin Deprecate mpsc channel selection Rationale: rust-lang#27800 (comment) r? @SimonSapin
Triage: this unstable feature was deprecated in 1.32, so it is fine to remove any time. |
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 |
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 |
@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. |
What's the succession story for waiting on two channels and taking from the first one that yields a message? |
Consider using another library such as https://crates.io/crates/crossbeam-channel |
How can one have channels and no selection between channels in the core language. |
Channels are not in the core language; they are in the standard library. |
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. |
@havelund As linked above, use a library: https://crates.io/crates/crossbeam-channel |
Yes thanks. I found it. It seems to work fine. |
Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle, Select}`, which were all unstable and have been deprecated since 1.32. Closes #27800 r? @SimonSapin
For what it's worth, I ended up at this issue because I was trying to find out what happened to the |
Is there still any discussion about deprecating |
|
@SimonSapin I read @dralley's proposal as replacing the internals, not the API, but could be wrong? |
Not my proposal just to be clear, I'm just curious as to whether any action items had ever come out of that discussion. |
As someone who came to love Go, coded in it professionally for almost a year, and subsequently fell out of love with it (generics, performance, package management, code gen hell), the lack of Select in the standard library in Rust is what is preventing me from adopting it. If I need high performance and I'm going to have to rely on external code for concurrency support anyways, I might as well go with the path of least resistance and write in C. |
@Ace-Cassidy You just need to add |
@Ace-Cassidy Rust is designed to have a minimal standard library so that different components can evolve their APIs and bump their versions independently from each other. You'll also need external crates (maintained by Rust team members) for things like random number generation ( |
…ting among mpsc channels: rust-lang/rust#27800.
This is a tracking issue for the unstable
mpsc_select
feature in the standard library. Known points:The text was updated successfully, but these errors were encountered: