However! Erlang doesn't have any hard real time guarantees
But this, from the end of the GRiSP page, is interesting:
* When Erlang is running on RTEMS there is very little latency between something happening on the hardware and a reaction on the Erlang level. There is strict control over what can pre-empt the Erlang VM: only hardware interrupts allowed. In practice, this means Erlang’s soft real-time is not as soft as on normal operating systems.
For the future, we plan to provide hard real-time processes on the Erlang level; GRiSP-Base will be the main test platform for this.
That's really exciting especially with respect to how Erlang's GC model works. I haven't used it in anger but everything I've read seems that Erlang doesn't have a need to stop-the-world GC since there's no shared state and processes can just drop their pool when they die without the need to collect.
Pauses for GC are per-actor for the Erlang VM, so indeed no stop-the-world, or if there is, it's a very low latency sync point where the GC to switches mode.
There are plenty of soft and hard real-time GCs though suitable for use with any GC'd language. For instance, the CHICKEN collector in [1] is an absurdly simple copying collector with an observed maximum pause time of 120 microseconds with average pauses of 1 microsecond.
Low-latency GC tends to sacrifice a little throughput though, which is why it's not more widely used. Relative to a standard concurrent MS, CHICKEN adds up to 30% in execution time, although the average seems to hover around 10-15%.
Yes that also means the latency is not very long since in normal Erlang processes the process heap is also quite small so it doesn't take long to collect. Even without our planned extensions to the Erlang VM its astonishing well behaved in real world realtime applications.
Soft/hard realtime was always a spectrum and basically the point of hard-realtime is never reached in practice (if your hardware dies or glitches you miss your deadline, caches are hard to model but you't want to switch them off etc).
Even without changed VM one can enforce garbage collection at certain points which moves Erlang on the throughput/realtime spectrum more towards realtime. Not worth it if a non realtime OS schedules you but of value when controlling exactly who can preempt you (under RTEMS no-one is feasible)
But this, from the end of the GRiSP page, is interesting:
* When Erlang is running on RTEMS there is very little latency between something happening on the hardware and a reaction on the Erlang level. There is strict control over what can pre-empt the Erlang VM: only hardware interrupts allowed. In practice, this means Erlang’s soft real-time is not as soft as on normal operating systems.
For the future, we plan to provide hard real-time processes on the Erlang level; GRiSP-Base will be the main test platform for this.