4 ms·

Erlang's BEAM, assuming no chicanery of NIFs, will use reduction counting to eventually yield a scheduler to make sure other Erlang processes get execution time

Erlang's BEAM, assuming no chicanery of NIFs, will use reduction counting to eventually yield a scheduler to make sure other Erlang processes get execution time. This gives you kind of a "will eventually happen" property. It can't guarantee meeting a deadline. Just that all things will be serviced at some point.

elcritch 1y ago
Right GRiSP has support for creating RTOS tasks in C, IIRC. Within BEAM itself there’s no priority mechanism, however, on a RPi3 or BeagleBone you could get about an 200 uS average response time to GPIO on Linux, even under moderate load. The jitter was pretty low too, like 10-20 uS on average, but the 99.9% tail latencies could get up to hundreds of millis. That’s fine for many use cases. Still I now prefer programming on esp32’s with Nim for anything realtime. Imperative programming just makes handling arrays easier. Just wish FreeRTOS tasks had error handling akin to OTP supervisors. Now Beam/Elixir would be amazing for something like HomeAssistant or large networked control systems.
- harrisi 1y ago
  Erlang does have a mechanism to modify process priority, with process_flag/2,3. As of OTP 28 there's also priority messaging that a process can opt in to. Not really related, but it's new and interesting to note.
  - jacquesm 1y ago
    > As of OTP 28 there's also priority messaging that a process can opt in to. That's a very important feature. Without priority messaging you can't nicely recover from queues that start backing up.
- actionfromafar 1y ago
  Just a reminder that commonly "real-time" on stuff like VxWorks isn't hard realtime either. You test a bunch of scenarios, put in some execution CPU head-room you are comfortable with, and call it a day. With enough head-room and some more (or less, if you have money and time) hand-waving, you can more or less guarantee that deadlines will be kept.

elcritch 1y ago

Right GRiSP has support for creating RTOS tasks in C, IIRC. Within BEAM itself there’s no priority mechanism, however, on a RPi3 or BeagleBone you could get about an 200 uS average response time to GPIO on Linux, even under moderate load. The jitter was pretty low too, like 10-20 uS on average, but the 99.9% tail latencies could get up to hundreds of millis. That’s fine for many use cases. Still I now prefer programming on esp32’s with Nim for anything realtime. Imperative programming just makes handling arrays easier. Just wish FreeRTOS tasks had error handling akin to OTP supervisors. Now Beam/Elixir would be amazing for something like HomeAssistant or large networked control systems.

harrisi 1y ago
Erlang does have a mechanism to modify process priority, with process_flag/2,3. As of OTP 28 there's also priority messaging that a process can opt in to. Not really related, but it's new and interesting to note.
- jacquesm 1y ago
  > As of OTP 28 there's also priority messaging that a process can opt in to. That's a very important feature. Without priority messaging you can't nicely recover from queues that start backing up.
actionfromafar 1y ago
Just a reminder that commonly "real-time" on stuff like VxWorks isn't hard realtime either. You test a bunch of scenarios, put in some execution CPU head-room you are comfortable with, and call it a day. With enough head-room and some more (or less, if you have money and time) hand-waving, you can more or less guarantee that deadlines will be kept.