On Mon, Aug 12, 2013 at 5:13 PM, Brian Anderson <[email protected]> wrote: > On 08/11/2013 10:42 AM, Corey Richardson wrote: >> >> I've opened a pull request for basic runtimeless support on libstd: >> https://github.com/mozilla/rust/pull/8454 >> >> I think it needs a wider discussion. I think it's very desirable to >> have a libstd that can be used without a runtime, especially once we >> have static linking and link-time DCE. As it stands, this patch is >> more of a hack. It removes swaths of libstd that currently can't work >> without a "runtime", but adds some simple stub implementations of the >> free/malloc lang items that call into the libc, so really it requires >> a C runtime. >> >> What I think we should end up with is various "levels" of runtime. >> Some environments can provide unwinding, while others can't, for >> example. You can mix-and-match various cfgs for specific pieces of the >> runtime to get a libstd that can run on your platform. Other things >> require explicit language items (think zero.rs). Thankfully the >> compiler now errors when you use something that requires a language >> item you don't implement, so it's easy to see what you need and where. >> I envision a sort of "platform file" that implements language items >> for a specific platform, and you'd include this in the libstd build >> for the platform. >> >> But libstd, as it stands, is insanely dependant on a full, robust >> runtime, especially task failure and TLS. A runtimeless libstd can't >> depend on either of those. You can see the hack in str.rs to not use >> conditions when no_rt is given. >> >> While I don't think my PR should be merged as-is, I think the >> discussion for the best way to achieve what it accomplishes correctly >> is important. > > > There are a lot of different interrelated use cases here. > > * Some users don't want to use green threads for whatever reason > * Some platforms can't support green threads (JS) > * Some use cases don't want to link to libc (kernels, maybe > microcontrollers) > * Some don't want to or can't link to libc++ or libuv > * Some platforms can't support threads (JS, microcontrollers?) > > Simply talking about a std without a runtime is troublesome, since what > exactly the runtime is isn't clear, and really it is specific features that > are untenable in different scenarios. It would probably be most productive > to identify specific use cases and make Rust work there instead of just > having a goal of removing the runtime. From my perspective, making std work > in emscripten is probably the coolest project, but there are also a lot of > people interested in microcontrollers so that would be a good avenue to > explore too. > > Some of the big problem areas in Rust's runtime semantics are unwinding and > task-local storage - but also anything that depends on task-local state. To > make this work without green threads I expect to add another subtype of > `Task` that is not a coroutine (#8474). It should be compatible with most > environments. Of course, if you consider tasks to be runtime, and you want a > runtimeless rust, then this may be unsatisfying still. This is why I no > longer think of this goal as 'runtimeless' but as 'profiles' - to have full > Rust functionality you really need to have some implementation of the task > abstraction. Though maybe in a single-threaded environment where `fail!()` > can mean `abort()` you could imagine not having a task at all while > preserving most functionality - still though it seems like we're going down > the path of using conditions more and those require local storage, so I > don't think we're going to get away from thread-local/task-local state as a > firm requirement for std. > > I guess I don't have any specific advice here besides to work toward a > specific, testable use-case, and do it in small steps that have minimal > impact on the common case. I will say that the current patch that sprinkles > `#[cfg(not(no_rt))]` in *very many* places is pretty tough to swallow. Good > luck. >
This is very valuable feedback, thank you! I'll mull on it a bit and see if I can't come up with something better, targeting the case of simple libc-only environment (as I think that will be easiest), or a more detailed RFC. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
