Refreshing post. This is way above my skis. What's interesting to me is that explaining why someone would want deterministic models clarified why someone would want a nondeterministic model. As long as you have a way to make the properties you care about invariant, then you can let the actual implementation be whatever. You also might not want to use a deterministic concurrency model to deal with faults. The point is working around the nondeterminism that the actual implementation experiences. This is a conceit of Erlang, to accept that there are nondeterministic parts of the system, but that the recovery from them is deterministic. You could probably model fault as an input in the Reactor model and then model fault recovery.
What's interesting about the Reactor model is you don't have to accept that combining two deterministic processes automatically makes it nondeterministic. That has to be super useful for real world systems.
What's interesting about the Reactor model is you don't have to accept that combining two deterministic processes automatically makes it nondeterministic. That has to be super useful for real world systems.
His seminal paper "The problem with threads" [0] and others inspired [1] a lot.
Boy would I love to see what would have happened if he and Joe Armstrong would have collaborated...
[0] https://ptolemy.berkeley.edu/publications/papers/06/problemw...
[1] https://edms.etas.com/