Move UV to its own crate. #10058
Move UV to its own crate. #10058
Conversation
|
I also wanted to mention that we should not be linking I don't believe that our linking model is currently well suited to express functionality like this, but it's also not a high-priority issue. |
|
One change which I've now snuck in here is removing the The only use case for this was the crate map, and it turned out that the crate map needed even more special treatment than just the I'm personally in favor of this issue because |
Primarily this makes the Scheduler and all of its related interfaces public. The reason for doing this is that currently any extern event loops had no access to the scheduler at all. This allows third-party event loops to manipulate the scheduler, along with allowing the uv event loop to live inside of its own crate.
|
The #[event_loop_factory] lang item implies that multiple crates that implement the event loop can't be used interchangeably (because we'd be linking in two event loop factory lang items). In other words, if |
|
The compiler doesn't appear to use the 'event_loop' lang item. Is it really needed? |
| Some(factory) => return factory() | ||
| } | ||
| } | ||
| } |
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.
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 rust-lang#5019
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.
There used to be a logical bug where IncrementVisitor would completely stop checking an expression/block after seeing a continue statement. This led to issue rust-lang#10058 where a variable incremented (or otherwise modified) after any continue statement would still be considered incremented only once. The solution is to continue scanning the expression after seeing a `continue` statement, but increment self.depth so that the Visitor thinks that the rest of the loop is within a conditional.
…Frednet fix logic in IncrementVisitor There used to be a logical bug where IncrementVisitor would completely stop checking an expression/block after seeing a continue statement. I am a little unsure of whether my fix to `IncrementVisitor` is logically sound (I hope it makes sense). Let me know what you think, and thanks in advance for the review! fixes rust-lang#10058 --- changelog: FP: [`explicit_counter_loop`]: No longer ignores counter changes after `continue` expressions [rust-lang#10094](rust-lang/rust-clippy#10094) <!-- changelog_checked -->
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
librustuvas a completely separate library. This library is then injected (viaextern 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_factorylanguage 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 theevent_loop_factorylanguage 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::startpath.