3 ms·

Concurrency might be a dangerous thing but in microcontroller land, where I do my C programming, interrupts are a fact of life and just polling really isn't a p

Concurrency might be a dangerous thing but in microcontroller land, where I do my C programming, interrupts are a fact of life and just polling really isn't a practical solution.

MuffinFlavored 8y ago
Is that how Rust concurrency works under the hood? Polling?
- steveklabnik 8y ago
  Rust has no particular built-in model for concurrency or threading. The standard library currently exposes system threads, and we’re working on providing an API for pluggable concurrency models. The most popular of which is a wrapper around epoll/kqueue/iocp.
  - MuffinFlavored 8y ago
    Rust has no particular built-in model for concurrency, but as soon as you want to do anything important with Rust (given the current ecosystem) you're going to run into Tokio, no? It seems to be the community-agreed-upon way to handle concurrency. Does Tokio use polling under the hood?
    - steveklabnik 8y ago
      There are a number of different options. And today, yes, code is tied to one of them. But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. This lets your code be generic over executors, and there are already more than just tokio. Including an embedded one, for example. Tokio wraps epoll/kqueue/iocp.
      - MuffinFlavored 8y ago
        > But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. Is this implementation going to wrap epoll/kqueue/iocp? Would you say Tokio has any drawbacks/flaws/design choices yo aren't a fan of? What are the popular choices other than Tokio?
        steveklabnik 8y ago
        Traits are not implementations, just interfaces. There won't be an implementation of one in std, just the interface, so that the ecosystem can interoperate. At the moment, I think Tokio is pretty great. I wish that there was more development bandwidth to help test out some cutting-edge stuff, but I think the design is sound. It really depends, Tokio is the most popular at the moment. This is because most of the new ecosystem is built around these new, unstable interfaces. Tokio currently runs on the older, not in the standard library one. It's all a bit confusing at the moment, to be honest.
    - bb010g 8y ago
      For the OP's microcontrollers, there's the excellent Real Time For The Masses: https://japaric.github.io/cortex-m-rtfm/book/en/ https://japaric.github.io/cortex-m-rtfm/book/en/
- rhn_mk1 8y ago
  The "fearless concurrency" advertised in Rust, which I believe the author is referring to, describes concurrent execution.
- arghwhat 8y ago
  No. Rusts memory model allows for the program to be validated at compile-time. It means that broken concurrency code won't compile. (In some cases, you may need to defer validation to runtime by using wrapper types such as RefCell or Mutex, in which case the usual cost of mutexes and the likes appear.) However, what was referred to is using interrupts vs. polling on embedded hardware. This is very different from regular software development.

Concurrency might be a dangerous thing but in microcontroller land, where I do my C programming, interrupts are a fact of life and just polling really isn't a practical solution.

MuffinFlavored 8y ago

Is that how Rust concurrency works under the hood? Polling?

steveklabnik 8y ago
Rust has no particular built-in model for concurrency or threading. The standard library currently exposes system threads, and we’re working on providing an API for pluggable concurrency models. The most popular of which is a wrapper around epoll/kqueue/iocp.
- MuffinFlavored 8y ago
  Rust has no particular built-in model for concurrency, but as soon as you want to do anything important with Rust (given the current ecosystem) you're going to run into Tokio, no? It seems to be the community-agreed-upon way to handle concurrency. Does Tokio use polling under the hood?
  - steveklabnik 8y ago
    There are a number of different options. And today, yes, code is tied to one of them. But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. This lets your code be generic over executors, and there are already more than just tokio. Including an embedded one, for example. Tokio wraps epoll/kqueue/iocp.
    - MuffinFlavored 8y ago
      > But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. Is this implementation going to wrap epoll/kqueue/iocp? Would you say Tokio has any drawbacks/flaws/design choices yo aren't a fan of? What are the popular choices other than Tokio?
      - steveklabnik 8y ago
        Traits are not implementations, just interfaces. There won't be an implementation of one in std, just the interface, so that the ecosystem can interoperate. At the moment, I think Tokio is pretty great. I wish that there was more development bandwidth to help test out some cutting-edge stuff, but I think the design is sound. It really depends, Tokio is the most popular at the moment. This is because most of the new ecosystem is built around these new, unstable interfaces. Tokio currently runs on the older, not in the standard library one. It's all a bit confusing at the moment, to be honest.
  - bb010g 8y ago
    For the OP's microcontrollers, there's the excellent Real Time For The Masses: https://japaric.github.io/cortex-m-rtfm/book/en/ https://japaric.github.io/cortex-m-rtfm/book/en/
rhn_mk1 8y ago
The "fearless concurrency" advertised in Rust, which I believe the author is referring to, describes concurrent execution.
arghwhat 8y ago
No. Rusts memory model allows for the program to be validated at compile-time. It means that broken concurrency code won't compile. (In some cases, you may need to defer validation to runtime by using wrapper types such as RefCell or Mutex, in which case the usual cost of mutexes and the likes appear.) However, what was referred to is using interrupts vs. polling on embedded hardware. This is very different from regular software development.