Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bastion – Highly-available distributed fault-tolerant runtime

github.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Bastion – Highly-available distributed fault-tolerant runtime

#21

Post by zzzcpan »

elteto wrote: post #13

How is runtime fault-tolerance achieved? My understanding of Erlang is that the BEAM VM implements these capabilities (custom threads, supervision, restarts, hot reload), but it is one level removed and above actual code. And they implement their own user-space threading runtime in order to support them. But in Rust, there is no such runtime (or is Bastion implementing one?) and it seems like this is used as a librar…

By runtime fault-tolerance they probably just mean an ability to do programmable supervisors that can react to actors dying, nothing special. And it's not like you can do a lot from a user space process anyway, apart from catching signals and destroying a currently running actor that caused it.

Re: Bastion – Highly-available distributed fault-tolerant runtime

#22

Post by ignoramous »

elteto wrote: post #13

How is runtime fault-tolerance achieved? My understanding of Erlang is that the BEAM VM implements these capabilities (custom threads, supervision, restarts, hot reload), but it is one level removed and above actual code. And they implement their own user-space threading runtime in order to support them. But in Rust, there is no such runtime (or is Bastion implementing one?) and it seems like this is used as a librar…

> How is runtime fault-tolerance achieved?

An actor is:

1. A lightproc, which, per my understanding, are async-spawned threads returning (optional?) Futures [0].

2. A ProcHandle [1] that lets you define process-state (like pid), control process-exec (like cancel, suspend?), listen on progress of a given lightproc that is run by BastianExecutors [2], whilst the message passing / supervisor semantics is handled by Bastion [3].

https://akka.io/ on JVM would be a better comparison to this than BEAM's implementation of actors, I think.

[0] https://github.com/bastion-rs/bastion/blob/2d9dc705962f30fbf...

[1] https://github.com/bastion-rs/bastion/blob/2d9dc705962f30fbf...

[2] https://github.com/bastion-rs/bastion/blob/2d9dc705962f30fbf...

[3] https://docs.rs/bastion/0.3.4/bastion/struct.Bastion.html

Re: Bastion – Highly-available distributed fault-tolerant runtime

#23

Post by davidw »

hopia wrote: post #20
davidw wrote: post #18

Looks like good work! I'm curious about why I might use this instead of Erlang.

I was also wondering if this is aiming to be the Erlang for Rust developers , or rather a better Erlang . Either one would probably be worthwhile.

Yeah, either one is pretty cool.

If it's 'Erlang for Rust developers' I'd be curious to get a feel for how well it integrates with everything. A lot of what Erlang does is kind of difficult to shoehorn in via a library, but I don't know Rust well so maybe it all integrates in a very natural way.

Re: Bastion – Highly-available distributed fault-tolerant runtime

#24

Post by StreamBright »

blattimwind wrote: post #15
elteto wrote: post #13

How is runtime fault-tolerance achieved? My understanding of Erlang is that the BEAM VM implements these capabilities (custom threads, supervision, restarts, hot reload), but it is one level removed and above actual code. And they implement their own user-space threading runtime in order to support them. But in Rust, there is no such runtime (or is Bastion implementing one?) and it seems like this is used as a librar…

Erlang's use of m:n threading is orthogonal to fault-tolerance (perhaps not inside the implementation, but conceptually).

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 runtime

#25

Post by elteto »

blattimwind wrote: post #15
elteto wrote: post #13

How is runtime fault-tolerance achieved? My understanding of Erlang is that the BEAM VM implements these capabilities (custom threads, supervision, restarts, hot reload), but it is one level removed and above actual code. And they implement their own user-space threading runtime in order to support them. But in Rust, there is no such runtime (or is Bastion implementing one?) and it seems like this is used as a librar…

Erlang's use of m:n threading is orthogonal to fault-tolerance (perhaps not inside the implementation, but conceptually).

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 runtime

#26

Post by zzzcpan »

elteto wrote: post #25
blattimwind wrote: post #15

Earlier quoted context omitted.

Erlang's use of m:n threading is orthogonal to fault-tolerance (perhaps not inside the implementation, but conceptually).

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.

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 runtime

#27

Post by blattimwind »

elteto wrote: post #25
blattimwind wrote: post #15

Earlier quoted context omitted.

Erlang's use of m:n threading is orthogonal to fault-tolerance (perhaps not inside the implementation, but conceptually).

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.

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 runtime

#28

Post by saagarjha »

elteto wrote: post #25
blattimwind wrote: post #15

Earlier quoted context omitted.

Erlang's use of m:n threading is orthogonal to fault-tolerance (perhaps not inside the implementation, but conceptually).

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.

> Suppose an OS thread goes into an infinite loop. How do you cleanly stop it (feel free to assume Linux/Windows/MacOS)?

ptrace it?

Re: Bastion – Highly-available distributed fault-tolerant runtime

#29

Post by gavinray »

spurdoman77 wrote: post #16

Can someone elaborate use cases for this?

To provide context, understanding this requires a little bit of background knowledge about concurrency paradigms.

In concurrent programming, there are a few mental models/approaches you can use to achieve it. Each of them have different "values systems" and tradeoffs, if you will.

In a nutshell, you have:

- Locks (Mutex/Semaphore)

- Communicating Sequential Processes

- Software Transactional Memory

- Actor Model

The Actor Model is a particularly powerful paradigm because it isolates processes and works via message passing and spawning. The reason why Erlang/Elixir are fault-tolerant is because of the BEAM's process model, any given process (more or lesss) can fail and it's not a problem due to isolation.

What this library allows you to do is architect applications in ways such that they are much more resilient to failure and easier to scale out + parallelize/distribute.

It doesn't have to be a networked application either, any code process can be an actor. It applies to any software.

If you want a great overview of the Actor model, there are some slides here which do a fantastic job of illustrating it:

https://cs.nyu.edu/wies/teaching/ppc-14/material/lecture10.p...

Post reply on HN