Hi Corey, It's great to see that people are thinking more and more about integrating Rust in existing languages!
I wonder however whether the other alternative has been envisioned: if Rust requires a runtime to work properly (specifically: TLS, task failure), would it be possible to provide an external caller the ability to setup the runtime before calling Rust methods ? I have absolutely no idea whether this is sensible or possible, but maybe rather than either extreme (a full runtime setup vs a no runtime mode) there is a way to meet in the middle; with a core runtime that can be set from a C interface (TLS ? ...) and then a set of cfgs for various additional pieces (such as garbage collection ? ...). -- Matthieu On Sun, Aug 11, 2013 at 7:42 PM, Corey Richardson <co...@octayn.net> 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. > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
