This is great !! Quick question - it seems like rustpkg is still unaware of libnative and libgreen ? I am trying to compile the example code from alex (and some other examples) with rustpkg with the following error:
> rustpkg build test WARNING: The Rust package manager is experimental and may be unstable error: Package test depends on native, but I don't know how to find it task '<unnamed>' failed at 'explicit failure', /private/tmp/rust-yVG2/src/librustpkg/util.rs:528 task '<unnamed>' failed at 'receiving on a closed channel', /private/tmp/rust-yVG2/src/libstd/comm/mod.rs:728 However, rustc does it just fine ... > rustc -o bin/test src/test/main.rs > Wondering if there is a pending issue with rustpkg ? I am happy (and prefer) to use rustc anyways! Great work !! Dr. Madhu Srinivasan > Date: Sat, 28 Dec 2013 17:15:54 -0800 > From: [email protected] > To: [email protected] > Subject: Re: [rust-dev] Using libgreen/libnative > > Thanks for writing this up, Alex. The improvements you've made to the > runtime recently are very impressive. Now we've got nearly complete and > reasonably fast I/O, fast message passing, a scheduler-agnostic standard > library, and very soon an embeddable runtime and a standard library that > can be used in almost any environment. After years of iteration I'm > hopeful that we're finally converging on a good design for the runtime. > > > On 12/28/2013 10:37 AM, 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
