3 ms·

Really anything beyond the standard posix one process many threads model. One process and no threads is how erlang does it as far as I can tell. Edit: No that'

Really anything beyond the standard posix one process many threads model. One process and no threads is how erlang does it as far as I can tell. Edit: No that's not exactly true http://stackoverflow.com/questions/7005759/erlang-on-multicore-cpu http://stackoverflow.com/questions/7005759/erlang-on-multico... But they do spawn a processes for each core.

geofft 11y ago
How do you run code on multiple cores? (What's your kernel in this case, if it's non-POSIX?)
- 15155 11y ago
  Send some kind of very-low-level interrupt, pointing each core at code to run, I am guessing? I could see Rust's ownership and multithreading amenability being extremely useful at this level, but admittedly I don't know enough.
  - dbaupp 11y ago
    Isn't that exactly what a thread is? Well, threads generally have some management by the OS to allow more threads than CPU/share tasks evenly, but at their core, they allow you to give each core some code to run on. (And yes, Rust's threading safety applies equally well to that. It doesn't care about the details of how code is running concurrently/in parallel, just that it could be.)
jamii 11y ago
Erlang will use multiple OS threads if you start it with '-smp enabled'. Otherwise it would be limited to a single core. Each thread runs a scheduler and the many Erlang processes are balanced between the schedulers. There is still only one OS process though. http://erlang.2086793.n4.nabble.com/Some-facts-about-Erlang-and-SMP-td2108770.html http://erlang.2086793.n4.nabble.com/Some-facts-about-Erlang-...
- geofft 11y ago
  Yeah, that's well-suited to Rust's design (although Rust didn't ship with libgreen, the requirements of libgreen influenced the type system, and you can do a similar thing with a third-party library). In any case the distinction between "multiple processes" and "multiple threads" here is fairly minimal, at least on Linux or OS X. As far as the kernel is concerned, they're the same object (Linux calls them threads; Mach calls them tasks). It's just that sometimes, groups of these things share pointers to things like memory map or file descriptor table, and sometimes they have their own pointers. There isn't a whole lot of difference, either at the language level or the kernel level, between running multiple processes from the same executable image that map a shared heap versus just running multiple threads.

geofft 11y ago

How do you run code on multiple cores? (What's your kernel in this case, if it's non-POSIX?)

15155 11y ago
Send some kind of very-low-level interrupt, pointing each core at code to run, I am guessing? I could see Rust's ownership and multithreading amenability being extremely useful at this level, but admittedly I don't know enough.
- dbaupp 11y ago
  Isn't that exactly what a thread is? Well, threads generally have some management by the OS to allow more threads than CPU/share tasks evenly, but at their core, they allow you to give each core some code to run on. (And yes, Rust's threading safety applies equally well to that. It doesn't care about the details of how code is running concurrently/in parallel, just that it could be.)

jamii 11y ago

Erlang will use multiple OS threads if you start it with '-smp enabled'. Otherwise it would be limited to a single core. Each thread runs a scheduler and the many Erlang processes are balanced between the schedulers. There is still only one OS process though. http://erlang.2086793.n4.nabble.com/Some-facts-about-Erlang-and-SMP-td2108770.html http://erlang.2086793.n4.nabble.com/Some-facts-about-Erlang-...

geofft 11y ago
Yeah, that's well-suited to Rust's design (although Rust didn't ship with libgreen, the requirements of libgreen influenced the type system, and you can do a similar thing with a third-party library). In any case the distinction between "multiple processes" and "multiple threads" here is fairly minimal, at least on Linux or OS X. As far as the kernel is concerned, they're the same object (Linux calls them threads; Mach calls them tasks). It's just that sometimes, groups of these things share pointers to things like memory map or file descriptor table, and sometimes they have their own pointers. There isn't a whole lot of difference, either at the language level or the kernel level, between running multiple processes from the same executable image that map a shared heap versus just running multiple threads.