rustc: Switch defaults from libgreen to libnative

[alexcrichton]

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

[lilyball]

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.

[alexcrichton]

selecting across I/O and channels at the same time

I don't understand how that's relevant to this change. Any solution would encompass both libgreen and libnative.

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.

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.

Heck, I don't think we even have a solution right now for selecting over multiple I/O streams alone

This also seems unrelated to the green/native default.

[lilyball]

@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).

[brson]

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.

[thestinger]

@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.

[alexcrichton]

ping r?