4 ms·
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 set
by 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 agoYou'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 agoOf 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 agoWell 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 agoYeah, that's what I meant with LING (Erlang on xen).