[rust-dev] Using libgreen/libnative

Greetings rusticians! Recently pull request #10965 landed, so the rust standard library no longer has any scheduling baked into it, but rather it's refactored out into two libraries. This means that if you want a 1:1 program, you can jettison all M:N support with just a few `extern mod` statements. A brief overview of the current state of things is: 1. All programs not using std::rt directly should still continue to operate as usual today 2. All programs still start up in M:N mode, although this will likely change once 1:1 I/O work has been completed 3. There are two more libraries available, libgreen and libnative, which allow custom fine-grained control over how programs run. 4. Whenever a new task is spawned, it is by default spawned as a "sibling" which means that it is spawned in the same mode as the spawning thread. This means that if a green thread spawns a thread then it will also be a green thread, while a native thread will spawn another OS thread. With this migration, there have been a few changes in the public APIs, and things still aren't quite where I'd like them to be. PR #11153 is the last major step in this process as it allows you to link to both libnative and libgreen, yet still choose which one is used to boot your program. Some breaking changes you may notice are: * it's still not possible to easily start up in 1:1 mode - This is fixed by #11153. In the meantime, you can use #[start] with native::start in order to boot up in 1:1 mode. Be warned though that the majority of I/O is still missing from libnative (see PR #11159 for some progress) https://gist.github.com/8162357 * std::rt::{start, run} are gone - These are temporarily moved into green/native while #[boot] is getting sorted out. The green/native counterparts perform as you would expect. https://gist.github.com/8162372 * std::rt::start_on_main_thread is gone - This function has been removed with no direct counterpart. As a consequence of refactoring the green/native libraries, the "single threaded" spawn mode for a task has been removed (this doesn't make sense in 1:1 land). This behavior can be restored by directly using libnative and libgreen. You can use libgreen to spin up a pool of schedulers and then use libnative for the main task to do things like GUI management. https://gist.github.com/8162399 And of course with the removal of some features comes the addition of new ones! Some new things you may notice are: * libstd is no longer burdened with libgreen and libnative! This means that the compile times for libstd should be a little faster, but most notably those applications only using libstd will have even less code pulled in than before, meaning that libstd is that much closer to being used in a "bare metal" context. It's still aways off, but we're getting closer every day! * libgreen has a full-fleged SchedPool type. You can see a bit of how it's used in gist I posted above. This type is meant to represent a dynamic pool of schedulers. Right now it's not possible to remove a scheduler from the pool (requires some more thought and possibly libuv modifications), but you can add new schedulers dynamically to the pool. This type supercedes the ThreadPool type in libextra at this point, and management of a SchedPool should provide any fine-grained control needed over the 'M' number in an M:N runtime. * libgreen and libnative can be used directly to guarantee spawning a green or a native task, regardless of the flavor of task that is doing the spawning. In the coming months, I plan on filling out more native I/O to bring it up to speed with the M:N implementation. I also plan on rewriting the core components of extra::comm to be performant in both scheduling modes in order to bring the extra::{comm, arc, sync} primitives up to date with their std::comm counterparts. If there are any questions about any of this, feel free to ask me! This thread is always available, and I'm also reachable as acrichto on IRC or alexcrichton on github.