Re:Bastion – Highly-available distributed fault-tolerant run...
by blattimwind on Monday February 24, 2020 @09:59AM
(#22404479)
Erlang's use of m:n threading is orthogonal to fault-tolerance (perhaps not inside the implementation, but conceptually).
[ Parent
| on HN ]
Re:Bastion – Highly-available distributed fault-tolerant run...
by StreamBright on Monday February 24, 2020 @12:44PM
(#22406290)
If an Erlang process crash cannot crash the entire system while Bastion's concept of a process can then threading is important part of fault-tolerance, isn't it?
Re:Bastion – Highly-available distributed fault-tolerant run...
by elteto on Monday February 24, 2020 @12:54PM
(#22406424)
It definitely is not orthogonal. Suppose an OS thread goes into an infinite loop. How do you cleanly stop it (feel free to assume Linux/Windows/MacOS)?. In Erlang this is possible because of the custom threading implementation.
Re:Bastion – Highly-available distributed fault-tolerant run...
by blattimwind on Monday February 24, 2020 @01:06PM
(#22406530)
In Erlang that's possible because the program runs in a VM. Erlang could do the same with 1:1 and m:1 threading.
Re:Bastion – Highly-available distributed fault-tolerant run...
by zzzcpan on Monday February 24, 2020 @01:06PM
(#22406525)
It's because of the vm interpreter that calls into the scheduler within loop iterations. Nothing to do with threads.
Re:Bastion – Highly-available distributed fault-tolerant run...
by chrisseaton on Monday February 24, 2020 @03:00PM
(#22407822)
> How do you cleanly stop it
The JVM manages this - there are many options:
- reading a flag - patching the running - changing memory protection and causing a segfault