support as well.
* The runtime should not enforce separate "modes of compilation" in order to
- work in multiple circumstances. Is it an explicit goal that you compile a Rust
+ work in multiple circumstances. It is an explicit goal that you compile a Rust
library once and use it forever (in all environments).
* The runtime should be fast. There should be no architectural design barrier
The full complement of runtime features is defined by the [`Runtime`
trait](std/rt/trait.Runtime.html) and the [`Task`
struct](std/rt/task/struct.Task.html). A `Task` is constant among all runtime
-implementations, but each runtime implements has its own implementation of the
+implementations, but each runtime has its own implementation of the
`Runtime` trait.
The local `Task` stores the runtime value inside of itself, and then ownership
With two implementations of the runtime available, a choice obviously needs to
be made to see which will be used. The compiler itself will always by-default
-link to one of these runtimes. At the time of this writing, the default runtime
-is `libgreen` but in the future this will become `libnative`.
+link to one of these runtimes.
Having a default decision made in the compiler is done out of necessity and
convenience. The compiler's decision of runtime to link to is *not* an
extern crate rustuv;
#[start]
-fn start(argc: int, argv: **u8) -> int {
+fn start(argc: int, argv: *const *const u8) -> int {
green::start(argc, argv, rustuv::event_loop, main)
}
extern crate native;
#[start]
-fn start(argc: int, argv: **u8) -> int { native::start(argc, argv, main) }
+fn start(argc: int, argv: *const *const u8) -> int {
+ native::start(argc, argv, main)
+}
fn main() {}
~~~