On 12/28/2013 04:12 PM, Huon Wilson wrote:
This is awesome!
I have a question: does the #[boot] addition mean that we now have 5
ways to (partially) set-up the entry point of a program?
- fn main
- #[main]
- #[start]
- #[boot]
- #[lang="start"]
Yeah, pretty much, and there's also a 6th way of defining an entry point
- by using #[no_main] and just defining main like in C. Alex and I had a
pretty decent laugh when we decided to add #[boot] to the mix. Note
though that #[boot] won't define a new entry point - it just changes how
the runtime configures itself before running main. Clearly, this is
getting pretty silly and this will continue to evolve, and hopefully
we'll end up in a spot where most users don't need to know about all
these mechanisms.
Huon
On 29/12/13 05:37, Alex Crichton wrote:
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.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
