Tracking issue for channel selection

[alexcrichton]

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]

cc me

[steveklabnik]

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

[steveklabnik]

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

[alexcrichton]

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]

@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]

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

[carllerche]

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]

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

[softprops]

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]

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]

@BurntSushi nice!