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.
-Brian
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
