Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Some work on freestanding Rust: foreign calls, exchange allocator #4619
This is some initial work on freestanding Rust I've had sitting around. It is needed to write scheduler code in Rust.
It does two major things:
My intent was to write the exchange heap allocator in Rust but after I did so I noticed that there are still a number of C++ utility functions that make exchange heap allocations. As a result there is one written in Rust and one written in C++ (that both just use malloc), and they share a global atomic reference count of allocations. This change loses some of the debugging facilities provided by the existing
r+ overall, I trust you have a plan here. I'm confused about a number of elements and left a few line comments but don't let me slow you down. I'm fine with the multiplication of wonky allocators as stopgap measures; we're going to have a much more serious allocator -- or set of allocators -- at some point this year, this is all transitional.
For my own understanding: I realize bug #4457 uses the term "without a runtime", but to be precise: "without a runtime" is used here as an exact synonym for "running in a thread that hasn't put a task pointer in TLS", correct? There are enough moving pieces here that I think it pays to be precise in what we're talking about / doing.
(The potential additional state of "has a task pointer in TLS but it's not accurate due to someone switching stacks without updating TLS" is ... one of the reasons I'd like to move to pulling the task pointer out of
@graydon Yes that is what I mean here by 'without a runtime'. Lately I think of 'the runtime' and 'the scheduler' as the same thing. This isn't going to get us to a true freestanding rust any time soon, but I think what people mostly want (and what we need) is to execute rust code without the scheduler. I hope to make it clear which parts of core rely on the scheduler and which don't.
Regarding the issue of updating TLS, I don't yet understand the solution you are proposing and how it relates to our current implementation. Let's talk about it on IRC some time.