rustc: Switch defaults from libgreen to libnative #12833
Conversation
|
I'm not comfortable making this change until we have a better solution for selecting across I/O and channels at the same time. The current solution requires spawning two tasks per I/O channel, which is acceptable (if not ideal) with libgreen but seems rather poor with libnative. Heck, I don't think we even have a solution right now for selecting over multiple I/O streams alone, besides wrapping them in channels and using the poor solution referred to above. |
I don't understand how that's relevant to this change. Any solution would encompass both libgreen and libnative.
That's why we wrote libgreen as well as libnative, you get to choose. As I wrote in the commit message, there is no right choice, there's just something that we feel is an appropriate default.
This also seems unrelated to the green/native default. |
|
@alexcrichton Any library that needs to select across I/O alone, or I/O and channels, is forced to use the workaround of two channels/tasks per I/O. Superfluous tasks that are expected to be blocked for 99% of their life is a decent fit for libgreen tasks but is pretty crappy for libnative threads. But libraries don't have any control over their threading (unless their API is such that they're capable of setting up their own task pool and blocking on it, but that's uncommon). |
|
Having to use a lot of tasks for I/O is not great under either threading regime, and I/O needs to be easier still regardless of this patch. Native threading is the right default for Rust and I hope we can get it in for the 0.10 release. |
|
@kballard: The memory consumption is the same either way, as it's dominated by the stack. I don't think leaving a thread blocked is worse with a native thread as it's not actually going to be doing any context switching. |
|
ping r? |
The compiler will no longer inject libgreen as the default runtime for rust programs, this commit switches it over to libnative by default. Now that libnative has baked for some time, it is ready enough to start getting more serious usage as the default runtime for rustc generated binaries. We've found that there isn't really a correct decision in choosing a 1:1 or M:N runtime as a default for all applications, but it seems that a larger number of programs today would work more reasonable with a native default rather than a green default. With this commit come a number of bugfixes: * The main native task is now named "<main>" * The main native task has the stack bounds set up properly * #[no_uv] was renamed to #[no_start] * The core-run-destroy test was rewritten for both libnative and libgreen and one of the tests was modified to be more robust. * The process-detach test was locked to libgreen because it uses signal handling
This removes even more rust_builtin.c code, and allows us to more gracefully handle errors (not a process panic, but a task failure).
The details can be found in the comment I wrote on the block in question, but the gist of it is that our usage of the TIB for a stack limit was causing CryptAcquireContext to fail, so we temporarily get around it by setting the stack limit to 0.
The compiler will no longer inject libgreen as the default runtime for rust programs, this commit switches it over to libnative by default. Now that libnative has baked for some time, it is ready enough to start getting more serious usage as the default runtime for rustc generated binaries. We've found that there isn't really a correct decision in choosing a 1:1 or M:N runtime as a default for all applications, but it seems that a larger number of programs today would work more reasonably with a native default rather than a green default. With this commit come a number of bugfixes: * The main native task is now named `<main>` * The main native task has the stack bounds set up properly * #[no_uv] was renamed to #[no_start] * The core-run-destroy test was rewritten for both libnative and libgreen and one of the tests was modified to be more robust. * The process-detach test was locked to libgreen because it uses signal handling
Add proc-macro-srv integration test that clones literals This exercises some of the upcoming proc_macro bridge changes. It should also pass for all supported ABIs, with the older-style bridge. This changed is tracked in: * rust-lang/rust-analyzer#12818
Rephrase and expand `empty_enum` documentation. * Remove incorrect claim that “wrappers around it are the conventional way to define an uninhabited type”. * Discuss why one would use `!`, a newtype struct, or keep the enum. * Add links to relevant documentation. Before writing this change, I asked the community via [IRLO](https://internals.rust-lang.org/t/idiomatic-definition-of-uninhabited-never-newtypes/20877) and [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Never.20type.20wrappers.20.2F.20defining.20uninhabited.20newtypes) for feedback. The broad consensus seemed to me to be that in a world where both `never_type` and `min_exhaustive_patterns` are stable and therefore available for general use, we _might_ want to `!` or newtypes of it — but it's certainly not “conventional” _yet._ Therefore, I've removed “conventional” and added a discussion of the pros and cons of different choices. changelog: [`empty_enum`]: expanded documentation
The compiler will no longer inject libgreen as the default runtime for rust
programs, this commit switches it over to libnative by default. Now that
libnative has baked for some time, it is ready enough to start getting more
serious usage as the default runtime for rustc generated binaries.
We've found that there isn't really a correct decision in choosing a 1:1 or M:N
runtime as a default for all applications, but it seems that a larger number of
programs today would work more reasonably with a native default rather than a
green default.
With this commit come a number of bugfixes:
<main>one of the tests was modified to be more robust.