Re:A Taste of Rust
by eridius on Sunday May 17, 2015 @02:27AM
(#9558950)
> when you are writing systems code, sometimes you either do not have a kernel, or are writing one
If you're writing kernel code, you have to abandon most of Rust's standard library already, because there's lots of stuff that isn't available. This is one of the reasons why Rust's standard library is split into a bunch of different crates (that are all then re-exposed under the "libstd" facade), so you can pick and choose which bits of functionality you can actually use. If you're in the kernel, you probably can't use the user-space allocator, which means you have to drop liballoc, which means you have to drop most of the standard library. AIUI, kernels are pretty much constrained to using just libcore and then reimplementing other functionality as needed. Most relevant to this conversation, this generally means you have to drop the standard library's I/O and threading support entirely (userspace code that creates threads isn't really going to work in the kernel).
And at that point, there's absolutely nothing stopping you from implementing an actor model yourself. Heck, that's what the Rust standard library used to do! Although it used libuv, which presumably doesn't work in kernelspace, which means you wouldn't have even been able to use Rust's green threading from kernel code even if it was never dropped.
> submitting to kernel threads means you must also give all cores over to the kernel as well, leading to competition between your program and others
I'm not sure what you mean by this. A green threading implementation is built on top of OS threads anyway (using a small pool of threads roughly equivalent to one per core, with extra threads as necessary for the green threading implementation to do blocking tasks). There's nothing at all about green threading that lets you control a core all to yourself without sharing it with other processes. If your OS lets you request priority for a specific core, you can do that for OS threads just as well as you could with green threads.
If you're writing kernel code, you have to abandon most of Rust's standard library already, because there's lots of stuff that isn't available. This is one of the reasons why Rust's standard library is split into a bunch of different crates (that are all then re-exposed under the "libstd" facade), so you can pick and choose which bits of functionality you can actually use. If you're in the kernel, you probably can't use the user-space allocator, which means you have to drop liballoc, which means you have to drop most of the standard library. AIUI, kernels are pretty much constrained to using just libcore and then reimplementing other functionality as needed. Most relevant to this conversation, this generally means you have to drop the standard library's I/O and threading support entirely (userspace code that creates threads isn't really going to work in the kernel).
And at that point, there's absolutely nothing stopping you from implementing an actor model yourself. Heck, that's what the Rust standard library used to do! Although it used libuv, which presumably doesn't work in kernelspace, which means you wouldn't have even been able to use Rust's green threading from kernel code even if it was never dropped.
> submitting to kernel threads means you must also give all cores over to the kernel as well, leading to competition between your program and others
I'm not sure what you mean by this. A green threading implementation is built on top of OS threads anyway (using a small pool of threads roughly equivalent to one per core, with extra threads as necessary for the green threading implementation to do blocking tasks). There's nothing at all about green threading that lets you control a core all to yourself without sharing it with other processes. If your OS lets you request priority for a specific core, you can do that for OS threads just as well as you could with green threads.