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

Open
alexcrichton opened this Issue Aug 13, 2015 · 70 comments

Comments

Projects
None yet
@alexcrichton
Member

alexcrichton commented Aug 13, 2015

This is a tracking issue for the unstable mpsc_select feature in the standard library. Known points:

  • The API is unsafe, and should probably never be stabilized.
  • Servo apparently makes very heavy use of this API, so it can't be removed without replacement currently.
  • The correctness of the implementation is somewhat dubious, it's incredibly complicated.
  • The macro-based approach for selection is dubious.
  • This is not a scalable implementation of selection (e.g. "poll everything each time wait() is called")
  • This drags down some other channel-related code with a few mutexes in otherwise lock-free code.
@jdm

This comment has been minimized.

Show comment
Hide comment
@jdm

jdm Aug 13, 2015

Contributor

cc me

Contributor

jdm commented Aug 13, 2015

cc me

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik
Member

steveklabnik commented Aug 13, 2015

Is it worth investigating @BurntSushi 's https://github.com/BurntSushi/chan ?

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Aug 13, 2015

Member

I also think @carllerche was supporting the idea of removing channels from the stdlib

Member

steveklabnik commented Aug 13, 2015

I also think @carllerche was supporting the idea of removing channels from the stdlib

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Aug 13, 2015

Member

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.

Member

alexcrichton commented Aug 13, 2015

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.

@BurntSushi

This comment has been minimized.

Show comment
Hide comment
@BurntSushi

BurntSushi Aug 13, 2015

Member

@alexcrichton Correct. I doubt very much that chan will ever be lock free because I'm not convinced the semantics I want can be done with them. It's also much easier to implement. :-)

Member

BurntSushi commented Aug 13, 2015

@alexcrichton Correct. I doubt very much that chan will ever be lock free because I'm not convinced the semantics I want can be done with them. It's also much easier to implement. :-)

@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Aug 13, 2015

Contributor

I personally prefer the epoll-like design as implemented in comm.

Contributor

nagisa commented Aug 13, 2015

I personally prefer the epoll-like design as implemented in comm.

@carllerche

This comment has been minimized.

Show comment
Hide comment
@carllerche

carllerche Aug 13, 2015

Member

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...

Member

carllerche commented Aug 13, 2015

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...

@tripped

This comment has been minimized.

Show comment
Hide comment
@tripped

tripped Aug 20, 2015

Just hopping on to mention #12902 as one of the current weaknesses of the macro approach to select!.

tripped commented Aug 20, 2015

Just hopping on to mention #12902 as one of the current weaknesses of the macro approach to select!.

@softprops

This comment has been minimized.

Show comment
Hide comment
@softprops

softprops 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.

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.

@BurntSushi

This comment has been minimized.

Show comment
Hide comment
@BurntSushi

BurntSushi Sep 17, 2015

Member

Fwiw, channel selection with golang channels is part of what makes golang concurrency story so alluring to newcomers to go.

@softprops This doesn't address your primary concerns, but FYI, chan_select! in the chan crate was built to specifically match the semantics of Go's select.

Member

BurntSushi commented Sep 17, 2015

Fwiw, channel selection with golang channels is part of what makes golang concurrency story so alluring to newcomers to go.

@softprops This doesn't address your primary concerns, but FYI, chan_select! in the chan crate was built to specifically match the semantics of Go's select.

@softprops

This comment has been minimized.

Show comment
Hide comment
@softprops

softprops commented Sep 17, 2015

@BurntSushi nice!

@jonhoo

This comment has been minimized.

Show comment
Hide comment
@jonhoo

jonhoo May 1, 2016

Contributor

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?

Contributor

jonhoo commented May 1, 2016

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?

@szagi3891

This comment has been minimized.

Show comment
Hide comment
@szagi3891

szagi3891 May 1, 2016

Best to get rid of the macro select.
I made a working prototype that shows that it is possible:
https://github.com/szagi3891/channels_async-rs/blob/master/examples/select.rs#L76
Without any section unsafe.

szagi3891 commented May 1, 2016

Best to get rid of the macro select.
I made a working prototype that shows that it is possible:
https://github.com/szagi3891/channels_async-rs/blob/master/examples/select.rs#L76
Without any section unsafe.

@canndrew

This comment has been minimized.

Show comment
Hide comment
@canndrew

canndrew Jun 2, 2016

Contributor

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:

let ch0: Receiver<i32> = ...;
let ch1: Receiver<String> = ...;
match select((ch0, ch1)) {
    (x|!) => println!("Got an i32: {}", x),
    (!|y) => println!("Got a String: {}", y),
}
Contributor

canndrew commented Jun 2, 2016

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:

let ch0: Receiver<i32> = ...;
let ch1: Receiver<String> = ...;
match select((ch0, ch1)) {
    (x|!) => println!("Got an i32: {}", x),
    (!|y) => println!("Got a String: {}", y),
}
@BurntSushi

This comment has been minimized.

Show comment
Hide comment
@BurntSushi

BurntSushi Nov 2, 2016

Member

Is there anyone still using this API? I don't see any obvious path to stabilization. It would be nice to just remove it.

Member

BurntSushi commented Nov 2, 2016

Is there anyone still using this API? I don't see any obvious path to stabilization. It would be nice to just remove it.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 2, 2016

Member

@jdm is this still being used in Servo?

Member

alexcrichton commented Nov 2, 2016

@jdm is this still being used in Servo?

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Nov 2, 2016

Contributor

grep finds 4 instances of select! in servo master.

Contributor

SimonSapin commented Nov 2, 2016

grep finds 4 instances of select! in servo master.

@mattgreen

This comment has been minimized.

Show comment
Hide comment
@mattgreen

mattgreen 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. select! might be unstable but I can at least accomplish this.

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. select! might be unstable but I can at least accomplish this.

@softprops

This comment has been minimized.

Show comment
Hide comment
@softprops

softprops Nov 4, 2016

I've had only good experiences with https://github.com/BurntSushi/chan

softprops commented Nov 4, 2016

I've had only good experiences with https://github.com/BurntSushi/chan

@szagi3891

This comment has been minimized.

Show comment
Hide comment
@szagi3891

szagi3891 Nov 4, 2016

@mattgreen :
I think you should be able to replace this selecta! macoro of one channel.

This channel type will be :

enum Message {
    CtrlC,
    NormalMessage(....),
}

The main thread would send in theright time message Message::CtrlC.
The remainder of the program would send messages Message::NormalMessage

It makes sense ?

szagi3891 commented Nov 4, 2016

@mattgreen :
I think you should be able to replace this selecta! macoro of one channel.

This channel type will be :

enum Message {
    CtrlC,
    NormalMessage(....),
}

The main thread would send in theright time message Message::CtrlC.
The remainder of the program would send messages Message::NormalMessage

It makes sense ?

@antrik

This comment has been minimized.

Show comment
Hide comment
@antrik

antrik Nov 12, 2016

Contributor

Servo's ipc-channel library ( https://github.com/servo/ipc-channel ) also uses mpsc_select (for its inprocess back-end) -- which is a bit of a pain, since platforms relying on this back-end can't use ipc-channel with stable Rust. (See servo/ipc-channel#118 )

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 inprocess back-end is also being used for Android -- though I'm not sure why really...

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.

Contributor

antrik commented Nov 12, 2016

Servo's ipc-channel library ( https://github.com/servo/ipc-channel ) also uses mpsc_select (for its inprocess back-end) -- which is a bit of a pain, since platforms relying on this back-end can't use ipc-channel with stable Rust. (See servo/ipc-channel#118 )

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 inprocess back-end is also being used for Android -- though I'm not sure why really...

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.

@antrik

This comment has been minimized.

Show comment
Hide comment
@antrik

antrik Nov 12, 2016

Contributor

I'd like to point out that https://github.com/BurntSushi/chan -- which is being touted as a replacement for mpsc here -- doesn't really seem like a valid alternative to me: unlike mpsc, it has clonable and sharable receivers.

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 Mutex<> or Arc<Mutex<>> yourself when you know it's save and necessary for your application. (As mutexes are safe and easy to use in Rust -- unlike in Go -- I don't see any motivation for channels to double as a locking substitute...)

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...)

Contributor

antrik commented Nov 12, 2016

I'd like to point out that https://github.com/BurntSushi/chan -- which is being touted as a replacement for mpsc here -- doesn't really seem like a valid alternative to me: unlike mpsc, it has clonable and sharable receivers.

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 Mutex<> or Arc<Mutex<>> yourself when you know it's save and necessary for your application. (As mutexes are safe and easy to use in Rust -- unlike in Go -- I don't see any motivation for channels to double as a locking substitute...)

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...)

@BurntSushi

This comment has been minimized.

Show comment
Hide comment
@BurntSushi

BurntSushi Nov 12, 2016

Member

@antrik Please see the README for chan. Notably:

The purpose of this crate is to provide a safe concurrent abstraction for communicating sequential processes. Performance takes a second seat to semantics and ergonomics. If you're looking for high performance synchronization, chan is probably not the right fit.

There are a number of reasons why it doesn't necessarily replace std::sync::mpsc. Nevertheless, if you want to write in a CSP style in Rust, then I do think it's your only option on stable Rust because it gives you chan_select!. I suspect that's why people are bringing it up (which seems reasonable to me).

Member

BurntSushi commented Nov 12, 2016

@antrik Please see the README for chan. Notably:

The purpose of this crate is to provide a safe concurrent abstraction for communicating sequential processes. Performance takes a second seat to semantics and ergonomics. If you're looking for high performance synchronization, chan is probably not the right fit.

There are a number of reasons why it doesn't necessarily replace std::sync::mpsc. Nevertheless, if you want to write in a CSP style in Rust, then I do think it's your only option on stable Rust because it gives you chan_select!. I suspect that's why people are bringing it up (which seems reasonable to me).

@antrik

This comment has been minimized.

Show comment
Hide comment
@antrik

antrik Nov 12, 2016

Contributor

@BurntSushi as long as there is a general understanding that chan is a special-purpose library rather than a general replacement, that's perfectly fine -- I'm just concerned that there seems to be an air here of "we don't need to fix mpsc since there is chan", which I find rather disconcerting...

Contributor

antrik commented Nov 12, 2016

@BurntSushi as long as there is a general understanding that chan is a special-purpose library rather than a general replacement, that's perfectly fine -- I'm just concerned that there seems to be an air here of "we don't need to fix mpsc since there is chan", which I find rather disconcerting...

@antrik

This comment has been minimized.

Show comment
Hide comment
@antrik

antrik Nov 12, 2016

Contributor

To be perfectly clear, my point is that I believe there is a genuine need for mpsc to have a stable select; or failing that, at the very least for some other library that can indeed serve as a real drop-in replacement. (And is prominently featured as such -- I for one still think that the prevalent "go look around for some random crate that seems like it might fit this very basic need" mindset is seriously hurting the Rust ecosystem...)

Contributor

antrik commented Nov 12, 2016

To be perfectly clear, my point is that I believe there is a genuine need for mpsc to have a stable select; or failing that, at the very least for some other library that can indeed serve as a real drop-in replacement. (And is prominently featured as such -- I for one still think that the prevalent "go look around for some random crate that seems like it might fit this very basic need" mindset is seriously hurting the Rust ecosystem...)

@BurntSushi

This comment has been minimized.

Show comment
Hide comment
@BurntSushi

BurntSushi Nov 12, 2016

Member

I don't think anyone's really contesting that though? I think these are the facts on the ground as I know them:

  • mpsc_select hasn't seen any attention towards stabilizing it. I don't think there's even a viable proposal in existence at all.
  • It seems the only thing keeping mpsc_select around is Servo.
  • Some have found success by switching to chan. Heck, the fact that mpsc_select was unstable was one of the reasons why I wrote chan in the first place!
Member

BurntSushi commented Nov 12, 2016

I don't think anyone's really contesting that though? I think these are the facts on the ground as I know them:

  • mpsc_select hasn't seen any attention towards stabilizing it. I don't think there's even a viable proposal in existence at all.
  • It seems the only thing keeping mpsc_select around is Servo.
  • Some have found success by switching to chan. Heck, the fact that mpsc_select was unstable was one of the reasons why I wrote chan in the first place!
@p-kraszewski

This comment has been minimized.

Show comment
Hide comment
@p-kraszewski

p-kraszewski Dec 14, 2016

As a Rust newcomer from Erlang/Elixir world - I can live with MPSC.

My question is - do you have any comments on @szagi3891 approach for a static list of channels? Instead of selecting on let's say 2 channels, just .receive on one, carrying enum that is matched and dispatched later? Any do-s, don't-s, don't care-s?

p-kraszewski commented Dec 14, 2016

As a Rust newcomer from Erlang/Elixir world - I can live with MPSC.

My question is - do you have any comments on @szagi3891 approach for a static list of channels? Instead of selecting on let's say 2 channels, just .receive on one, carrying enum that is matched and dispatched later? Any do-s, don't-s, don't care-s?

@barr1969

This comment has been minimized.

Show comment
Hide comment
@barr1969

barr1969 Jan 5, 2017

Select on Dynamic Lists of Channels

As someone whose been using CSP for decades (though I've not yet used Rust), I feel compelled to submit a plea for the ability to select across dynamic lists of channels. This is such a useful thing to be able to do. It's particularly useful in large systems that have to deal with failure. That sounds like I'm effectively supporting @canndrew's suggestion. Lists that are fixed at compile time diminsh what can be achieved.

Locks, Why They're Not a Big Problem, and Program Architecture

On the topic of striving for a lock free implementation, I'm not convinced there's much merit in that if it results in too much ugliness in the implementation, pain, grief, anguish, etc.

If a receiver is selecting across one or more channels then it is implicitly content to wait for messages to arrive. So there's no real penality there from the receiver's point of view.

However, if the receiver never ends up waiting because the flow of messages exceeds its ability to process them, and this is seen as a performance problem (where a lock-free implementation might be seen as a way of improving performance), then my argument is that one's program's architecture is inadequate. The implication is that the receiver is a performance bottle neck.

The real solution is that there needs to be additional receivers, a separate channel to each one, and a means (e.g. either round robin, push pull, etc - the parallels with some of ZeroMQ's patterns and load balancing are not coincidental) for the sender to know to which one the next message should be sent.

The ideal architecture is one where there's enough parallel receivers to juuuuust ensure that the sender never has to block. The sender should always be finding that a receiver is available to receive a message.

The Actor model is often favoured because of its simplicity, but the runtime problems that might occur (deadlock, livelock, etc), are unpleasant. By using a strict CSP model, and getting the architecture just right, nothing ever blocks on send (just like Actor) but still achieves rendevous but with the added advantage of fixed latencies in data flow through your program. That's generally nice for real time things like streaming video, meeting performance targets, etc.

Now, if locks are used as part of the channel implementation, then the sender's end of a channel should then always be finding that the locks are available (because there's enough receivers to keep up with the required data flow rate). And if the locks are always available, they're probably quick to acquire.

So I'm basically suggesting that we probably shouldn't worry about an implementation using locks; if the locks are thought to be a problem, one's application architecture is likely to be more of an issue than the overhead of the locks.

barr1969 commented Jan 5, 2017

Select on Dynamic Lists of Channels

As someone whose been using CSP for decades (though I've not yet used Rust), I feel compelled to submit a plea for the ability to select across dynamic lists of channels. This is such a useful thing to be able to do. It's particularly useful in large systems that have to deal with failure. That sounds like I'm effectively supporting @canndrew's suggestion. Lists that are fixed at compile time diminsh what can be achieved.

Locks, Why They're Not a Big Problem, and Program Architecture

On the topic of striving for a lock free implementation, I'm not convinced there's much merit in that if it results in too much ugliness in the implementation, pain, grief, anguish, etc.

If a receiver is selecting across one or more channels then it is implicitly content to wait for messages to arrive. So there's no real penality there from the receiver's point of view.

However, if the receiver never ends up waiting because the flow of messages exceeds its ability to process them, and this is seen as a performance problem (where a lock-free implementation might be seen as a way of improving performance), then my argument is that one's program's architecture is inadequate. The implication is that the receiver is a performance bottle neck.

The real solution is that there needs to be additional receivers, a separate channel to each one, and a means (e.g. either round robin, push pull, etc - the parallels with some of ZeroMQ's patterns and load balancing are not coincidental) for the sender to know to which one the next message should be sent.

The ideal architecture is one where there's enough parallel receivers to juuuuust ensure that the sender never has to block. The sender should always be finding that a receiver is available to receive a message.

The Actor model is often favoured because of its simplicity, but the runtime problems that might occur (deadlock, livelock, etc), are unpleasant. By using a strict CSP model, and getting the architecture just right, nothing ever blocks on send (just like Actor) but still achieves rendevous but with the added advantage of fixed latencies in data flow through your program. That's generally nice for real time things like streaming video, meeting performance targets, etc.

Now, if locks are used as part of the channel implementation, then the sender's end of a channel should then always be finding that the locks are available (because there's enough receivers to keep up with the required data flow rate). And if the locks are always available, they're probably quick to acquire.

So I'm basically suggesting that we probably shouldn't worry about an implementation using locks; if the locks are thought to be a problem, one's application architecture is likely to be more of an issue than the overhead of the locks.

@jonhoo

This comment has been minimized.

Show comment
Hide comment
@jonhoo

jonhoo May 11, 2017

Contributor

As a separate suggestion, the eventual select interface should also have a try_recv() equivalent, as well as a recv_timeout(). I currently call try_recv() manually on each channel a couple of times before calling wait() to avoid incurring a thread sleep/wakup cycle, and being able to instead call try_recv directly on the Select would be much better.

Contributor

jonhoo commented May 11, 2017

As a separate suggestion, the eventual select interface should also have a try_recv() equivalent, as well as a recv_timeout(). I currently call try_recv() manually on each channel a couple of times before calling wait() to avoid incurring a thread sleep/wakup cycle, and being able to instead call try_recv directly on the Select would be much better.

@jonhoo

This comment has been minimized.

Show comment
Hide comment
@jonhoo

jonhoo Jul 6, 2017

Contributor

Another use-case that's been bothering me lately is if I have multiple channels, some of which are likely to always be non-empty. The current Select implementation does not give any kind of guarantee of fairness, and if the first channel mentioned in the Select always has an element available, the other channels will never be read from.

EDIT: For reference, Go chooses the next channel to try in a select pseudo-randomly.

Contributor

jonhoo commented Jul 6, 2017

Another use-case that's been bothering me lately is if I have multiple channels, some of which are likely to always be non-empty. The current Select implementation does not give any kind of guarantee of fairness, and if the first channel mentioned in the Select always has an element available, the other channels will never be read from.

EDIT: For reference, Go chooses the next channel to try in a select pseudo-randomly.

@adrianbrink

This comment has been minimized.

Show comment
Hide comment
@adrianbrink

adrianbrink Aug 15, 2017

Is this an unstable feature that I can already use on nightly?

adrianbrink commented Aug 15, 2017

Is this an unstable feature that I can already use on nightly?

bors-servo added a commit to servo/servo that referenced this issue Aug 5, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=<try>
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).

<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____

<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Aug 5, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=<try>
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).

<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____

<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Aug 6, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=<try>
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).

<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____

<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Aug 8, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=<try>
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).

<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____

<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Aug 30, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=jdm,SimonSapin
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Aug 30, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=jdm,SimonSapin
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Aug 30, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=jdm,SimonSapin
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 4, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=jdm
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 5, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=ferjm
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 5, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=jdm,SimonSapin
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 5, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=jdm,SimonSapin
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 5, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=jdm,SimonSapin
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 6, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=jdm
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 6, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=jdm
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 6, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=jdm
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 12, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=<try>
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 12, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=<try>
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 12, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=<try>
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 12, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=<try>
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 12, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=<try>
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 12, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=SimonSapin,jdm
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->

bors-servo added a commit to servo/servo that referenced this issue Sep 12, 2018

Auto merge of #21325 - gterzian:crossbeam_integration, r=SimonSapin,jdm
Replace mpsc with crossbeam-channel

Follow up on #19515

---

Selecting over multiple channels in `std::sync::mpsc` is not stable and likely never will be:

rust-lang/rust#27800 (comment)
> It seems the only thing keeping `mpsc_select` around is Servo.

crossbeam-channel is designed specifically to replace `std::sync::mpsc` and fix many of its shortcomings:
https://github.com/stjepang/rfcs-crossbeam/blob/channel/text/2017-11-09-channel.md

This is to be landed together with servo/ipc-channel#183.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/21325)
<!-- Reviewable:end -->
@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Sep 14, 2018

Contributor

With servo/servo#21325 merged (thanks @stjepang and @gterzian!), Servo does not use this feature anymore.

Do we know of other projects that do? Would it be useful to do a crater run (with something like renaming the feature flag) to find out?

@rust-lang/libs How do you feel we should proceed with this feature?

Contributor

SimonSapin commented Sep 14, 2018

With servo/servo#21325 merged (thanks @stjepang and @gterzian!), Servo does not use this feature anymore.

Do we know of other projects that do? Would it be useful to do a crater run (with something like renaming the feature flag) to find out?

@rust-lang/libs How do you feel we should proceed with this feature?

bors added a commit that referenced this issue Sep 14, 2018

Auto merge of #54228 - SimonSapin:mpsc_select_maybe_to_be_deprecated,…
… r=<try>

[Do not merge] Rename mpsc_select feature to break its users on Crater

CC #27800 (comment)
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Sep 14, 2018

Member

FWIW #54228 seems like a good way to proceed. I think if that's small enough we can probably just outright delete the feature, and if it's large we can do a round of messaging with a schedule to delete.

Member

alexcrichton commented Sep 14, 2018

FWIW #54228 seems like a good way to proceed. I think if that's small enough we can probably just outright delete the feature, and if it's large we can do a round of messaging with a schedule to delete.

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Sep 14, 2018

Contributor

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.

Contributor

SimonSapin commented Sep 14, 2018

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

Remove usage of the unstable, to-be-deprecated mpsc_select feature
The `select!` macro used in the tests in this repository is unstable
(only available on Nightly), but doesn’t have a clear path to stabilization
because of significant issues in its design:
rust-lang/rust#27800.

The Rust Library Team is considering this API for deprecation and eventual
removal. We found it used in this repository through Crater in
rust-lang/rust#54228.

In this case, it turns out that selection over two channels can be replaced
with waiting on a single channel with a custom `enum` for the message type,
and cloning the sender for sending from two different places/threads.
This PR implements that.

If you truely need selection over multiple channels, consider using
the [crossbeam-channel](https://crates.io/crates/crossbeam-channel) library.

If you feel that this feature should not be removed from the standard lirbray,
please comment on the tracking issue:
rust-lang/rust#27800

SimonSapin added a commit to SimonSapin/thread_isolated that referenced this issue Sep 16, 2018

Remove usage of the unstable, to-be-deprecated mpsc_select feature
The `select!` macro used in the tests in this repository is unstable
(only available on Nightly), but doesn’t have a clear path to stabilization
because of significant issues in its design:
rust-lang/rust#27800.

The Rust Library Team is considering this API for deprecation and eventual
removal. We found it used in this repository through Crater in
rust-lang/rust#54228.

In this case, it turns out that selection over two channels can be replaced
with waiting on a single channel with a custom `enum` for the message type,
and cloning the sender for sending from two different places/threads.
This PR implements that.

If you truely need selection over multiple channels, consider using
the [crossbeam-channel](https://crates.io/crates/crossbeam-channel) library.

If you feel that this feature should not be removed from the standard library,
please comment on the tracking issue:
rust-lang/rust#27800
@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Sep 16, 2018

Contributor

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 select! macro: #54228 (comment)

So let’s formally propose:

  • Emit a deprecation warning for usage of this feature
  • Wait for a few release cycles for remaining users to have an opportunity to see the warning and potentially comment here
  • Then, unless new information or arguments have come up, remove the feature.
  • According to this issue’s original message, this would allow removing some mutexes in the rest of the channels code to make it lock-free. Would someone be interested in working on that?

@rfcbot fcp close

Contributor

SimonSapin commented Sep 16, 2018

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 select! macro: #54228 (comment)

So let’s formally propose:

  • Emit a deprecation warning for usage of this feature
  • Wait for a few release cycles for remaining users to have an opportunity to see the warning and potentially comment here
  • Then, unless new information or arguments have come up, remove the feature.
  • According to this issue’s original message, this would allow removing some mutexes in the rest of the channels code to make it lock-free. Would someone be interested in working on that?

@rfcbot fcp close

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot 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 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

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Sep 19, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot commented Sep 19, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment