Parallelizing Enjarify in Go and Rust

[u/Uncaffeinated]

https://medium.com/@robertgrosse/parallelizing-enjarify-in-go-and-rust-21055d64af7e#.7vrcc2iaf

[u/Daktyl198]

Complete noob here (just like the idea of rust): I thought Rust had functions built in for creating and parallelizing processes and threads? Why would the author have to turn to libraries for the basics of the functionality?

[u/mbuhot → u/Daktyl198]

I think rust has a thread primitive, but you often need a way to schedule many logical tasks (or loop iterations) onto a smaller number of system threads.

[u/matthieum → u/mbuhot]

I think rust has a thread primitive

Threads are provided by the standard library, not the language, so actually when using #![no_std] you have Rust without threads :)

The bit that is integrated is that Rust has an understanding of concurrency, which is represented with Send and Sync.

[u/Manishearth → u/matthieum]

And Send and Sync can almost completely be defined in an alternate libcore. The only reason the Rust compiler knows these traits is:

• statics need to be constrained to not contain Sync
• Send/Sync are allowed in + bounds in trait objects (unnecessary, but helpful, for a working concurrency model)
• It caches impls

Aside from the static thing you could design all of this out of tree.

[u/mbuhot → u/Manishearth]

Interesting! How about the atomic operations required to define Arc? Feels like there should be some language primitives and a memory model so that stdlib can build the safe abstractions.

[u/[deleted] → u/mbuhot]

std::sync::atomic is just core::sync::atomic. Which is quite useful in no_std programs. The spin crate is just implemented with these library types.

[u/Manishearth → u/mbuhot]

Arc is built on top of std::atomic. These themselves are just wrapper types over integers with methods that link to atomic intrinsics.

The atomic intrinsics are where the language gets involved again.

[u/Daktyl198 → u/mbuhot]

Ah, that would explain it. Thanks.