This is currently a bug in rustpkg, and I've opened up https://github.com/mozilla/rust/issues/11243 about this bug.
On Tue, Dec 31, 2013 at 6:36 AM, Madhu Srinivasan <[email protected]> wrote: > 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 > _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
