implement a new task spawning model not depending on a managed runtime

[thestinger]

Blocking threads on their children adds significant overhead and implies that Rust needs to be hosted in a runtime that's not compatible with the C model. Rust should be able to run on threads started from C without giving up the concurrency libraries. Higher-level abstractions can be built upon the primitives provided by the standard library, but it's not the place of the standard library to force subjective high-level design decisions with overhead onto applications.

The native model has both detached threads without the overhead of synchronization between the parent and child (as there is no hierarchy) and threads represented by objects that are joined in the destructor to avoid the need for additional synchronization primitives like channels in common cases. Rust needs to move to a model like this in order to complete the runtime removal RFC.

The API also uses proc, which is probably going to change before 1.0 because it will be replaced as as a distinct type by Box<FnOnce<...>>. It might stay around as a form of sugar but marking any API using the old closures as stable is premature.

[pnkfelix]

Assigning P-backcompat-libs, not 1.0 milestone.

(Also, there will be a forthcoming RFC regarding the relationship of stability markers and semver, which may illuminate some of the meta issues here...)

[seanmonstar]

Any reason tasks require a boxed closure? Is it just to prevent codegen bloat of having such a common function use generics?

I'd be interested in spawning a task without the extra box.

[thestinger]

The overhead is insignificant due to the cost of making the stack allocation. It needs a to pass a function pointer and data parameter to a C function, and it needs to be bounded by Send. The Box<FnOnce<...>> type is the natural fit.