4 ms·

I like it. Platform threads should just be lightweight enough, that you don't have to patch on top of them. And if you really need to M:N behaviour, it is stil

I like it. Platform threads should just be lightweight enough, that you don't have to patch on top of them. And if you really need to M:N behaviour, it is still available as a library.

rubiquity 12y ago
Agreed. Defaulting to native threading gives developers so much more freedom. After all, M:N threading is just implemented on native threads anyway. You can still do that if you want to. Rust isn't going to be a systems language used only for networking, so forcing a M:N threading model on it doesn't make sense. This change was necessary to keep Rust as a general use systems programming language.
- dragonwriter 12y ago
  > Rust isn't going to be a systems language used only for networking, so forcing a M:N threading model on it doesn't make sense. M:N threading decouples degree of concurrency from degree of parallelism, which is not desirable only for networking. And the old way wasn't about forcing M:N threading, it was about providing a common interface for concurrency independent of the relation of concurrency to parallelism in the backend implementation. I can understand the idea that that abstraction may have been too expensive, but I can't get behind the idea that 1:1 threading as the only thing supported in the standard library somehow provides more freedom for developers.
  - dbaupp 12y ago
    Short-term it may look like there's less freedom since it's harder to use M:N threading (and 1:1 threading and M:N threading don't necessarily work perfectly together), but remember that the choice there is 1:1 threading with overhead and M:N threading with overhead. Long term, we can have libraries that provide M:N threading with minimal overhead; and also libraries that provide 1:1 & M:N together like the old std (with the associated overhead). That is, the programmer is getting more flexibility, just not right now (especially with Cargo, which makes it particularly easy to use external libraries). The team is trying to take a longer term view focusing std on safe interfaces to the OS primitives, which can then be used to build fancier/more abstract libraries more easily.
  - keeperofdakeys 12y ago
    It's not like people are saying "Rust will never have M:N threading", it's that the current implementation didn't offer enough advantages for the disadvantages it brought. https://github.com/aturon/rfcs/blob/remove-runtime/active/0000-remove-runtime.md https://github.com/aturon/rfcs/blob/remove-runtime/active/00... Having done some things with libgreen threads myself, they really didn't give anything over proper threads (especially without segmented stacks). So I am curious how this will evolve in the future.
lgunsch 12y ago
The two different threading models have different costs/benifits. Native threads are much faster at context switching then green threads, however, native threads have a significant startup cost where as spawning green threads is nearly cost-free.
- imanaccount247 12y ago
  >Native threads are much faster at context switching then green threads No, native threads have a much higher context switch overhead. The downside of green threads is the lack of parallelism, you can only use one CPU core. This is why decent languages multiplex green threads over OS threads (M:N). The mistake rust made was trying to make that distinction transparent.
  - lgunsch 12y ago
    Quote from Wikipedia article on Green Threads: "Linux native threads have slightly better performance on I/O and context switching operations." Some of the actual context switch in native threads is performed by the CPU, where as with green threads it is not. On top of this, the whole stack is copied upon a context switch.
    - ptx 12y ago
      The paper[1] cited for that quote is specifically about PersonalJava 1.1.3 on Linux 2.2 on PowerPC. It may not be relevant to implementations from this century. [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.9238&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.9...
    - imanaccount247 12y ago
      Your quote lacks the context which makes it clear that it is not a general claim. >Some of the actual context switch in native threads is performed by the CPU, where as with green threads it is not Exactly. Native threads have a context switch, green threads don't.
    - SamReidHughes 12y ago

I like it. Platform threads should just be lightweight enough, that you don't have to patch on top of them. And if you really need to M:N behaviour, it is still available as a library.

rubiquity 12y ago

Agreed. Defaulting to native threading gives developers so much more freedom. After all, M:N threading is just implemented on native threads anyway. You can still do that if you want to. Rust isn't going to be a systems language used only for networking, so forcing a M:N threading model on it doesn't make sense. This change was necessary to keep Rust as a general use systems programming language.

dragonwriter 12y ago
> Rust isn't going to be a systems language used only for networking, so forcing a M:N threading model on it doesn't make sense. M:N threading decouples degree of concurrency from degree of parallelism, which is not desirable only for networking. And the old way wasn't about forcing M:N threading, it was about providing a common interface for concurrency independent of the relation of concurrency to parallelism in the backend implementation. I can understand the idea that that abstraction may have been too expensive, but I can't get behind the idea that 1:1 threading as the only thing supported in the standard library somehow provides more freedom for developers.
- dbaupp 12y ago
  Short-term it may look like there's less freedom since it's harder to use M:N threading (and 1:1 threading and M:N threading don't necessarily work perfectly together), but remember that the choice there is 1:1 threading with overhead and M:N threading with overhead. Long term, we can have libraries that provide M:N threading with minimal overhead; and also libraries that provide 1:1 & M:N together like the old std (with the associated overhead). That is, the programmer is getting more flexibility, just not right now (especially with Cargo, which makes it particularly easy to use external libraries). The team is trying to take a longer term view focusing std on safe interfaces to the OS primitives, which can then be used to build fancier/more abstract libraries more easily.
- keeperofdakeys 12y ago
  It's not like people are saying "Rust will never have M:N threading", it's that the current implementation didn't offer enough advantages for the disadvantages it brought. https://github.com/aturon/rfcs/blob/remove-runtime/active/0000-remove-runtime.md https://github.com/aturon/rfcs/blob/remove-runtime/active/00... Having done some things with libgreen threads myself, they really didn't give anything over proper threads (especially without segmented stacks). So I am curious how this will evolve in the future.

lgunsch 12y ago

The two different threading models have different costs/benifits. Native threads are much faster at context switching then green threads, however, native threads have a significant startup cost where as spawning green threads is nearly cost-free.

imanaccount247 12y ago
>Native threads are much faster at context switching then green threads No, native threads have a much higher context switch overhead. The downside of green threads is the lack of parallelism, you can only use one CPU core. This is why decent languages multiplex green threads over OS threads (M:N). The mistake rust made was trying to make that distinction transparent.
- lgunsch 12y ago
  Quote from Wikipedia article on Green Threads: "Linux native threads have slightly better performance on I/O and context switching operations." Some of the actual context switch in native threads is performed by the CPU, where as with green threads it is not. On top of this, the whole stack is copied upon a context switch.
  - ptx 12y ago
    The paper[1] cited for that quote is specifically about PersonalJava 1.1.3 on Linux 2.2 on PowerPC. It may not be relevant to implementations from this century. [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.9238&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.9...
  - imanaccount247 12y ago
    Your quote lacks the context which makes it clear that it is not a general claim. >Some of the actual context switch in native threads is performed by the CPU, where as with green threads it is not Exactly. Native threads have a context switch, green threads don't.
  - SamReidHughes 12y ago