5 ms·
> Rust on little machines makes sense, but it needs more support underneath to deal with timers, interrupts, and concurrency. There are projects working on this
by dbaupp 9y ago
> Rust on little machines makes sense, but it needs more support underneath to deal with timers, interrupts, and concurrency. There are projects working on this.[1]
NB. the OP is part of that project, from the same author.
- Animats 9y agoRust needs a CPU dispatcher underneath, so the thread and lock primitives can work. A minimal single-process multiple-thread OS, something like VxWorks, is all that's needed. This would probably be something you'd link with the program. It's better to have one good one CPU dispatcher than making users roll their own crappy one for each application.
- dbaupp 9y agoWhat do you mean by 'need'? If you mean every Rust program requires a dispatcher to run, then no, Rust does not need a CPU dispatcher. Thread and locks are not primitives: they're implemented in the standard library (the std part, specifically). The 'thread' safety guarantees don't rely on that functionality, instead the arrows go the other way: the spawning and locking constructs build on the guarantees (driven by the Send and Sync traits, which are purely compile-time constructs) to provide expressive yet safe API. For instance, there's numerous operating systems built in Rust, for instance intermezzOS seems to be pure Rust except for the single file https://github.com/intermezzOS/kernel/blob/master/src/asm/boot.asm https://github.com/intermezzOS/kernel/blob/master/src/asm/bo... . If you mean that it would be really nice if there was a general purpose dispatcher library available, then sure, that seems like something that would be great on crates.io. In any case, I don't see how your comment relates to mine.
- Animats 9y agoRust with a CPU dispatcher offers the opportunity to get beyond the raw busy-wait and basic interrupt handling of Arduino-type code without going all the way to a full Linux system. That's what I'm getting at here.