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.
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
