Hacker News Reader

Comment by tomp | Hacker News Reader

You are correct.

(1) Rust disallows shared-memory concurrency (with a few exceptions), so each "task" has it's local heap. Only unique objects can be transferred from one task to another. This is similar to Erlang.

(2) They were using light-weight processes initially, but then transitioned to a 1-on-1 threading model, where each task runs on its own thread. IIRC it was to reduce the runtime library (lightweight threads require stack-growth handling and a user-mode scheduler).

View on HN

Rust actually supports both 1:1 and M:N threading models, depending on which one you want. It's true that it used to be M:N by default and is now 1:1 by default, though.

> Rust disallows shared-memory concurrency (with a few exceptions),

To elaborate: Rust eliminates mutable state being passed across a concurrency boundary at compile time. Sometimes, you really need shared mutable state, though, so you're able to use 'unsafe' to implement the safety the compiler can't infer for you. The obvious ones (only allowing access via a mutex and reference counting (both atomic and non)) are already in the standard library.

That's interesting with the M:N threading model. But would that require that I set the M/N ratio (or "multiplexing factor" or what to call it) to a fixed value, unlike the ability in Go to automatically multiplex any number of go-routines on the (fixed) number of OS threads?

Go's threading model is M:N threading. N is the fixed number of kernel threads, M is the variable number of application threads.

I'm not intimately familiar with Go's details here, but you can either just say 'run these green threads kthx' in which that factor is chosen for you, or you can use an explicit pool(s) and do it yourself.

Details: http://doc.rust-lang.org/green/index.html

libgreen will automatically pick a reasonable default number of OS threads to use if you don't, based on the number of CPU cores. (This is different from the way GOMAXPROCS works.) You may spawn any number of tasks and they will be automatically multiplexed onto those threads.

To be clear, unsafe code is not required to use shared state (even shared mutable state with atomics/locks). The unsafe code is encapsulated in the standard library and the types are set up such that it enforces safe, data-race-free usage of the primitives.

Right, the unsafe is an implementation detail. I guess I still consider that 'using' unsafe even if you didn't write it yourself.

Reply on news.ycombinator.com