[rust-dev] Using libgreen/libnative

Alex Crichton alex at crichton.co
Sat Dec 28 10:37:25 PST 2013


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.


More information about the Rust-dev mailing list