rust/src/libstd/rt/uv, branch master

Register new snapshots

2013-10-29T22:56:16+00:00

auto merge of #10058 : alexcrichton/rust/uv-crate, r=brson

2013-10-29T16:36:47+00:00

This is one of the final steps needed to complete #9128. It still needs a little bit of polish before closing that issue, but it's in a pretty much "done" state now. The idea here is that the entire event loop implementation using libuv is now housed in `librustuv` as a completely separate library. This library is then injected (via `extern mod rustv`) into executable builds (similarly to how libstd is injected, tunable via `#[no_uv]`) to bring in the "rust blessed event loop implementation." Codegen-wise, there is a new `event_loop_factory` language item which is tagged on a function with 0 arguments returning `~EventLoop`. This function's symbol is then inserted into the crate map for an executable crate, and if there is no definition of the `event_loop_factory` language item then the value is null. What this means is that embedding rust as a library in another language just got a little harder. Libraries don't have crate maps, which means that there's no way to find the event loop implementation to spin up the runtime. That being said, it's always possible to build the runtime manually. This request also makes more runtime components public which should probably be public anyway. This new public-ness should allow custom scheduler setups everywhere regardless of whether you follow the `rt::start `path.

Move rust's uv implementation to its own crate

2013-10-29T15:39:22+00:00

There are a few reasons that this is a desirable move to take: 1. Proof of concept that a third party event loop is possible 2. Clear separation of responsibility between rt::io and the uv-backend 3. Enforce in the future that the event loop is "pluggable" and replacable Here's a quick summary of the points of this pull request which make this possible: * Two new lang items were introduced: event_loop, and event_loop_factory. The idea of a "factory" is to define a function which can be called with no arguments and will return the new event loop as a trait object. This factory is emitted to the crate map when building an executable. The factory doesn't have to exist, and when it doesn't then an empty slot is in the crate map and a basic event loop with no I/O support is provided to the runtime. * When building an executable, then the rustuv crate will be linked by default (providing a default implementation of the event loop) via a similar method to injecting a dependency on libstd. This is currently the only location where the rustuv crate is ever linked. * There is a new #[no_uv] attribute (implied by #[no_std]) which denies implicitly linking to rustuv by default Closes #5019

Register new snapshots

2013-10-28T23:56:24+00:00

auto merge of #10093 : alexcrichton/rust/issue-8811, r=pcwalton

2013-10-28T12:36:31+00:00

Closes #8811

auto merge of #10083 : alexcrichton/rust/timer-port, r=pcwalton

2013-10-28T09:41:18+00:00

In addition to being able to sleep the current task, timers should be able to create ports which get notified after a period of time. Closes #10014

Allow fail messages to be caught, and introduce the Any trait

2013-10-28T07:50:32+00:00

Some code cleanup, sorting of import blocks Removed std::unstable::UnsafeArc's use of Either Added run-fail tests for the new FailWithCause impls Changed future_result and try to return Result<(), ~Any>. - Internally, there is an enum of possible fail messages passend around. - In case of linked failure or a string message, the ~Any gets lazyly allocated in future_results recv method. - For that, future result now returns a wrapper around a Port. - Moved and renamed task::TaskResult into rt::task::UnwindResult and made it an internal enum. - Introduced a replacement typedef `type TaskResult = Result<(), ~Any>`.

Ignore a test which never completes on windows

2013-10-27T17:58:32+00:00

I'm not entirely sure why this is happening, but the server task is never seeing the second send of the client task, and this test will very reliably fail to complete on windows.

Implement another error code found on windows.

2013-10-26T23:04:05+00:00

Closes #8811

auto merge of #10070 : alexcrichton/rust/fewer-missiles, r=brson

2013-10-26T07:06:09+00:00

This optimizes the `home_for_io` code path by requiring fewer scheduler operations in some situtations. When moving to your home scheduler, this no longer forces a context switch if you're already on the home scheduler. Instead, the homing code now simply pins you to your current scheduler (making it so you can't be stolen away). If you're not on your home scheduler, then we context switch away, sending you to your home scheduler. When the I/O operation is done, then we also no longer forcibly trigger a context switch. Instead, the action is cased on whether the task is homed or not. If a task does not have a home, then the task is re-flagged as not having a home and no context switch is performed. If a task is homed to the current scheduler, then we don't do anything, and if the task is homed to a foreign scheduler, then it's sent along its merry way. I verified that there are about a third as many `write` syscalls done in print operations now. Libuv uses write to implement async handles, and the homing before and after each I/O operation was triggering a write on these async handles. Additionally, using the terrible benchmark of printing 10k times in a loop, this drives the runtime from 0.6s down to 0.3s (yay!).