4 ms·

I wonder whether Erlang insome form could provide hard realtime guarantees. Something along the lines of LING.

troutwine 12y ago
It's an interesting question. I think you'd need at least: * a way to define scheduling requirements on a process level (beyond current, coarse, priority settings), * bounded process message queues (this would be handy in soft-realtime Erlang), * deadline accurate receives, * accurate control over resource allocation I've been meaning to sit down with some theory and think through this more analytically, but the above are my BART thinking-time derived set of requirements. I'm sure there are cases--some which would be obvious, in retrospect--that are not covered by the above.
- jacquesm 12y ago
  You'd have to run erlang directly on the hardware without an intermediary OS and you'd have to schedule the individual erlang processes using pre-emption and by giving them priorities. You'd also have to add a ready-list per priority. After all, as long as BEAM is running as a child process of a host os that is not hard realtime you can't guarantee much of anything.
  - troutwine 12y ago
    Of course. Apologies, I assumed that was a given. A large part of the appeal of Erlang the Language is Erlang the VM and the two aren't often divorced.
  - peerst 12y ago
    Well Erlang is running on RTEMS in production in industrial control systems http://www.grisp.org http://www.grisp.org Hard realtime processes to come
  - phamilton 12y ago
    Yeah, that's what I meant with LING (Erlang on xen).
peerst 12y ago
I have a project planned which when funded will give us hard realtime guarantees for certain Erlang processes. This can only work of course if the underlying OS is also hard realtime capable. I have ported Erlang to the open source RTEMS http://www.rtems.org http://www.rtems.org already. More details under http://www.grisp.org http://www.grisp.org (sorry website not up to date but soon will be).

It's an interesting question. I think you'd need at least: * a way to define scheduling requirements on a process level (beyond current, coarse, priority settings), * bounded process message queues (this would be handy in soft-realtime Erlang), * deadline accurate receives, * accurate control over resource allocation I've been meaning to sit down with some theory and think through this more analytically, but the above are my BART thinking-time derived set of requirements. I'm sure there are cases--some which would be obvious, in retrospect--that are not covered by the above.

jacquesm 12y ago
You'd have to run erlang directly on the hardware without an intermediary OS and you'd have to schedule the individual erlang processes using pre-emption and by giving them priorities. You'd also have to add a ready-list per priority. After all, as long as BEAM is running as a child process of a host os that is not hard realtime you can't guarantee much of anything.
- troutwine 12y ago
  Of course. Apologies, I assumed that was a given. A large part of the appeal of Erlang the Language is Erlang the VM and the two aren't often divorced.
- peerst 12y ago
  Well Erlang is running on RTEMS in production in industrial control systems http://www.grisp.org http://www.grisp.org Hard realtime processes to come
- phamilton 12y ago
  Yeah, that's what I meant with LING (Erlang on xen).

peerst 12y ago

I have a project planned which when funded will give us hard realtime guarantees for certain Erlang processes. This can only work of course if the underlying OS is also hard realtime capable. I have ported Erlang to the open source RTEMS http://www.rtems.org http://www.rtems.org already. More details under http://www.grisp.org http://www.grisp.org (sorry website not up to date but soon will be).