On 06/21/2013 02:53 PM, Thomas Daede wrote:
On Fri, Jun 21, 2013 at 4:17 PM, Brian Anderson <[email protected]> wrote:
On 06/21/2013 08:20 AM, Thomas Daede wrote:
- Compiling runtime and Core without thread support

This is a major refactoring project which isn't made any easier by the
current situation in which we have 2 entire runtimes.

https://github.com/mozilla/rust/issues/7282
I'm not sure what you mean by two entire runtimes. Are you referring
to the split between core and std?

We are in the process of rewriting the old C++ rust task scheduler (which to large degree is 'the Rust runtime') in Rust. At this moment and for at least another few weeks there is an entire C++ runtime implementation in src/rt and another in libstd/rt written in Rust. All the code paths in std that depend on runtime state currently have branches to pick between the two implementations, so an effort to refactor the libraries to create a microcontroller profile will have to deal with additional complexity.


- Adding compatibility with the newlib C library

Last time this came up we preferred musl.

https://github.com/mozilla/rust/issues/7283
I had never heard of musl, but it looks like it's Linux only, whereas
newlib is designed for "bare metal" or RTOS-based systems.

- Adding configurable stack allocation

I'm not sure this means in this context. Can you elaborate?
Right now Rust uses a segmented stack, and I believe the stack is
allocated in 4MB segments - which is way too huge. It would be better
to be able to set the size of the segments - or maybe fix the size of
the stack(s).

I didn't imagine you wanted to use green thread scheduling still. That will be interesting.

_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to