Repository navigation
RFC: Split core into core + rt #5157
Description
This is an RFC-level change but I don't have a full proposal just now. The basic idea is to make a new crate, rt, that depends on core, and all the scheduler, task, pipes, etc. code lives there. core contains modules for the primitive types, containers and a few other things.
This would mostly be an organizational change. Beyond freeing some niche users from linking to rt it doesn't really enable any new functionality. What it does is make a clear delineation between code that is tied to the scheduler and code that isn't.
By default, crates would link to both core and rt (as they now link to core and rustrt).
There aren't any significant technical obstacles that I know of, but it will require thinking about how task and comm fit into the prelude. Does the prelude live in rt? Do we just not put task and comm in the prelude?
Activity
brson commentedon Feb 28, 2013
This would require making some lang items optional and some overrideable. Exchange heap lang items would have implementations in both core and rt. Local heap items would only have an implementation in rt (though eventually we'll probably find a way to use the local heap outside of tasks).
catamorphism commentedon Feb 28, 2013
+1
brson commentedon Mar 12, 2013
This would cause some complications with stack growth since
__morestack, which is statically linked to every crate and called from every function, calls two functions in the runtime, but if core doesn't depend on the runtime then how can__morestackcall the runtime? We could possibly have core__morestackmake a virtual call through two globals that are set up by the runtime, but penalizing core is unfortunate. On the other hand, much of core is templates so the perf cost may not be too bad.brson commentedon Mar 14, 2013
Logging will present a similar problem to
__morestack.brson commentedon Mar 14, 2013
core::runspawns tasksbrson commentedon Mar 14, 2013
I was also planning on making the
iointerface use conditions, but conditions depend on tasks, so that would mean that core couldn't have its own blocking I/O implementation.brson commentedon Jun 13, 2013
I don't think this is feasible now. There is too much runtime code that must be available everywhere for e.g. failure.
Merge rust-lang#5154 rust-lang#5157