https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=master 2013-11-12T04:44:07+00:00 2013-11-12T04:44:07+00:00 Alex Crichton alex@alexcrichton.com 2013-11-11T06:46:32+00:00 urn:sha1:49ee49296b65f3d807142f3326bee71dd7e13290 2013-11-09T23:18:12+00:00 Young-il Choi duddlf.choi@samsung.com 2013-11-09T07:18:41+00:00 urn:sha1:e3f9f454390fe09643548070f6bd558676f9f32a 2013-11-03T23:15:42+00:00 Alex Crichton alex@alexcrichton.com 2013-10-26T00:04:37+00:00 urn:sha1:9c1851019f1ef9511fa8731b8f1acb0796d1e97f This commit moves all thread-blocking I/O functions from the std::os module. Their replacements can be found in either std::rt::io::file or in a hidden "old_os" module inside of native::file. I didn't want to outright delete these functions because they have a lot of special casing learned over time for each OS/platform, and I imagine that these will someday get integrated into a blocking implementation of IoFactory. For now, they're moved to a private module to prevent bitrot and still have tests to ensure that they work. I've also expanded the extensions to a few more methods defined on Path, most of which were previously defined in std::os but now have non-thread-blocking implementations as part of using the current IoFactory. The api of io::file is in flux, but I plan on changing it in the next commit as well. Closes #10057 2013-10-30T22:17:11+00:00 Alex Crichton alex@alexcrichton.com 2013-10-30T22:10:32+00:00 urn:sha1:452e5cdf11b30e17c69805a0bfc418feebb84081 Closes #9126 2013-10-29T16:36:47+00:00 bors bors@rust-lang.org 2013-10-29T16:36:47+00:00 urn:sha1:52f42f16387d0142944f376ea31c554c9caa2189 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. 2013-10-29T15:39:22+00:00 Alex Crichton alex@alexcrichton.com 2013-10-22T22:13:18+00:00 urn:sha1:201cab84e8f12ec73131ac4908e6779b277449a2 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 2013-10-29T02:26:23+00:00 bors bors@rust-lang.org 2013-10-29T02:26:23+00:00 urn:sha1:c0222cda27d0a1a06e7f227dfb1f0f6f87d2e742 This cropped up on the bsd bot, and if it's an error that gets thrown then it's fine to just whitelist another type of error in the test. 2013-10-28T18:47:20+00:00 Alex Crichton alex@alexcrichton.com 2013-10-28T18:47:20+00:00 urn:sha1:6c75b73a6ae3afd5690c0d1ab80c53e4f0a1fb86 This cropped up on the bsd bot, and if it's an error that gets thrown then it's fine to just whitelist another type of error in the test. 2013-10-26T23:04:05+00:00 Alex Crichton alex@alexcrichton.com 2013-10-26T23:04:05+00:00 urn:sha1:651f5db4623526d416458e9f77632e7dd72f96a8 Closes #8811 2013-10-24T21:21:58+00:00 Alex Crichton alex@alexcrichton.com 2013-10-18T04:08:48+00:00 urn:sha1:620ab3853abf99ecea3a3d055f47cd6d06433c95