[rust-dev] Why focus on single-consumer message passing?

Patrick Walton pcwalton at mozilla.com
Sun Jan 26 06:29:06 PST 2014

On 1/26/14 4:56 AM, Daniel Micay wrote:
> I don't think it's inflammatory or unspecific. Rust's standard library
> doesn't follow the pay-for-what-you-use philosophy and pulls in many
> megabytes of code via trait objects despite it not be used.

Still unspecific. What code exactly?

> It also
> forces the bindings to any library making use of thread-local storage
> (many!) to use painful context objects, even though it's unnecessary
> with 1:1 threading. C++ follows the philosophy of not making you pay
> for abstractions you aren't using.

Context objects are not painful; they are part of good library design. 
Libraries that don't use them are annoying to work with. OpenGL global 
state juggling is no fun, for example; any API that exposed OpenGL 
safely would possibly have to recreate context objects for memory safety.

In any case, if you used an M:N threading library such as lthread in 
C++, then you would have to do the same thing. If you don't want to pay 
for the abstraction in your library bindings, then don't support M:N 
threading. Rust doesn't force you one way or another.

M:N threading is like C++ RTTI or exceptions: the standard library 
exposes the ability to make it work but you don't have to use it. In 
fact, M:N threading in Rust is much more "pay-for-what-you-use" than C++ 
exceptions, as the C++ language is incomplete without exceptions 
(because there is no way to signal constructor failure) while there is 
no such dependency on M:N threading in Rust.

> A simple multi-consumer channel is faster than the current Rust
> channels with 1:1 threading

Bounded or unbounded?

In any case, Rust offers M:N threading, so this isn't very persuasive. 
M:N threading is not going to be removed until it is optimized and 
compared against the 1:1 implementation on all platforms.


More information about the Rust-dev mailing list