[rust-dev] Why focus on single-consumer message passing?
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