3 ms·

"embedded applications *that* can't have asynchronous execution" not "embedded applications can't have asynchronous execution" there are embedded application

• arlort 2y ago
  Yeah, I think I added a comma while reading by mistake so I thought the "that" was preceding the explanation of why you singled out embedded, my bad The point about a runtime optimized to run bare metal on a single core probably being suboptimal on a desktop machine with 8 cores still stands though. (And the laptop one is possibly not going to work optimally on a server with hundreds of core either)
• Dylan16807 2y ago
  I'm still skeptical that such a thing exists. A concurrency runtime doesn't have to be much more than a queue of function calls. What kind of hardware can run normal code but can't do that?
  • adastra22 2y ago
    Interrupt handlers, for example.
    • saagarjha 2y ago
      Depending on your implementation it is very possible to schedule interrupt handlers into a concurrent runtime. You'd have to be exceptionally careful about how it was designed with regards to, like, reentrancy, but Rust is quite good at encoding these kinds of things.
    • Dylan16807 2y ago
      An interrupt handler could schedule an asynchronous task just fine. In a lot of situations that would be a very good way to handle things. You shouldn't await in an interrupt handler, but there's a lot of things you shouldn't do in an interrupt handler. A rule like that doesn't mean you need a noasync mode. (And if you really wanted to use await there, you could make it work with priorities or with a separate task queue.)