5 ms·

Ok, I don't know rust at all, but often when I'm trying to understand a change, I look at how it affects the test cases. Seeing the diff in the test cases shou

by ikawe 12y ago

Ok, I don't know rust at all, but often when I'm trying to understand a change, I look at how it affects the test cases. Seeing the diff in the test cases should show how the API has changed, but I'm having a hard time reconciling the description of the changes with how the tests have changed. There are several occurrences of changes like this: - spawn(move|| { + Thread::spawn(move|| { tx.send(i); - }) + }).detach() Thread methods have been namespaced under "Thread::" and now a "detach" method is appended to each call to spawn. Can anyone shed some light?

maninalift 12y ago
The description notes the replacement of many uses of "tasks" with native OS threads. Tasks may map to threads or may be managed as green threads. Threads unlike tasks must be detached if they are too be allowed to outlive their parent.
kibwen 12y ago
In ancient Rust, the standard library attempted to provide an abstraction over the underlying threading model. The purpose of this abstraction, called a "task", was to allow libraries to make use of the standard concurrency constructs while allowing the consumers of those libraries to determine whether or not to use 1:1 threading (the typical platform thread model) or M:N threading (green threads), and it would all Just Work with no effort required. This was quite an exciting idea at the time. However, in practice, it just didn't pan out: the compromises required to paper over the differences between 1:1 threading and M:N threading managed to almost entirely obliterate the respective advantages of both models. As a result, Rust is in the process of removing the "tasks" abstraction and replacing it with a bog-standard 1:1 threading model (though it still benefits from all the typical memory-safe and concurrency-safe abstractions that Rust otherwise provides). All users of concurrency in the stdlib will now be using native threads, and it will be left to outside implementors to experiment with green threading libraries (see https://github.com/carllerche/mio https://github.com/carllerche/mio for one example of such). One of the consequences of this change is that the `std::task` module has been replaced with `std::thread`. Formerly, every Rust program imported the function `std::task::spawn` to use for spawning tasks. With the removal of `std::task`, the newly analogous function from `std::thread` has not been added to the prelude, and is therefore not imported by default in every Rust program. It could be added if such a thing were desired (you can see remarks to this effect in the comments on the PR itself (https://github.com/rust-lang/rust/pull/19654#issuecomment-66239082 https://github.com/rust-lang/rust/pull/19654#issuecomment-66... and https://github.com/rust-lang/rust/pull/19654#issuecomment-66956364 https://github.com/rust-lang/rust/pull/19654#issuecomment-66... )).
- mietek 12y ago
  What a disappointment.
  - kibwen 12y ago
    Can you elaborate?
    - smosher_ 12y ago
      Fwiw I think we were all disappointed when all that work and attention on a promising mechanism for having it both ways ultimately came to nothing.
      - kibwen 12y ago
        I concur. But I don't regret the time spent experimenting. Even negative results are valuable for advancing the state of the art.
        smosher_ 12y ago
        Yeah, I'm just trying to describe the above poster as reasonable before other readers jump on the opportunity to white-out the comment for no good reason.
    - mietek 12y ago
      There is not much to say which has not already been said. I think it is sad that so much effort is going into projects which do not advance the state of the art. First Go, now Rust — these high-profile projects draw people’s attention away from actually innovative work. As a core contributor, you will retort that Rust has different priorities than, say, Erlang, which is built around the concept of providing N:M processes (green threads) as a language primitive. My answer to that is, why not improve on Erlang, instead of settling for improving on C?
      - bjz_ 12y ago

by ikawe 12y ago

maninalift 12y ago

The description notes the replacement of many uses of "tasks" with native OS threads. Tasks may map to threads or may be managed as green threads. Threads unlike tasks must be detached if they are too be allowed to outlive their parent.

kibwen 12y ago

In ancient Rust, the standard library attempted to provide an abstraction over the underlying threading model. The purpose of this abstraction, called a "task", was to allow libraries to make use of the standard concurrency constructs while allowing the consumers of those libraries to determine whether or not to use 1:1 threading (the typical platform thread model) or M:N threading (green threads), and it would all Just Work with no effort required. This was quite an exciting idea at the time. However, in practice, it just didn't pan out: the compromises required to paper over the differences between 1:1 threading and M:N threading managed to almost entirely obliterate the respective advantages of both models. As a result, Rust is in the process of removing the "tasks" abstraction and replacing it with a bog-standard 1:1 threading model (though it still benefits from all the typical memory-safe and concurrency-safe abstractions that Rust otherwise provides). All users of concurrency in the stdlib will now be using native threads, and it will be left to outside implementors to experiment with green threading libraries (see https://github.com/carllerche/mio https://github.com/carllerche/mio for one example of such). One of the consequences of this change is that the `std::task` module has been replaced with `std::thread`. Formerly, every Rust program imported the function `std::task::spawn` to use for spawning tasks. With the removal of `std::task`, the newly analogous function from `std::thread` has not been added to the prelude, and is therefore not imported by default in every Rust program. It could be added if such a thing were desired (you can see remarks to this effect in the comments on the PR itself (https://github.com/rust-lang/rust/pull/19654#issuecomment-66239082 https://github.com/rust-lang/rust/pull/19654#issuecomment-66... and https://github.com/rust-lang/rust/pull/19654#issuecomment-66956364 https://github.com/rust-lang/rust/pull/19654#issuecomment-66... )).

mietek 12y ago
What a disappointment.
- kibwen 12y ago
  Can you elaborate?
  - smosher_ 12y ago
    Fwiw I think we were all disappointed when all that work and attention on a promising mechanism for having it both ways ultimately came to nothing.
    - kibwen 12y ago
      I concur. But I don't regret the time spent experimenting. Even negative results are valuable for advancing the state of the art.
      - smosher_ 12y ago
        Yeah, I'm just trying to describe the above poster as reasonable before other readers jump on the opportunity to white-out the comment for no good reason.
  - mietek 12y ago
    There is not much to say which has not already been said. I think it is sad that so much effort is going into projects which do not advance the state of the art. First Go, now Rust — these high-profile projects draw people’s attention away from actually innovative work. As a core contributor, you will retort that Rust has different priorities than, say, Erlang, which is built around the concept of providing N:M processes (green threads) as a language primitive. My answer to that is, why not improve on Erlang, instead of settling for improving on C?
    - bjz_ 12y ago