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.
Re:Erlang 28 on GRiSP Nano using only 16 MB
by jacquesm on Tuesday July 22, 2025 @10:19AM
(#44647224)
> 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.
Re:Erlang 28 on GRiSP Nano using only 16 MB
by actionfromafar on Tuesday July 22, 2025 @06:32AM
(#44645246)
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.
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.