Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Choice of framework (or DIY) to implement "reactors" #20

Closed
thanethomson opened this issue Sep 4, 2019 · 7 comments
Closed

Choice of framework (or DIY) to implement "reactors" #20

thanethomson opened this issue Sep 4, 2019 · 7 comments
Labels
structure High level repo-wide structural concerns

Comments

@thanethomson
Copy link
Contributor

As per #19, one of the decisions we have to make is whether to roll our own reactor framework (as in the Go version of Tendermint) or use an existing framework (such as Actix, based on Tokio) to handle all that for us.

Whichever approach we choose, we should abstract the relevant reactor functionality in such a way that we can swap out the framework at a later stage if necessary. This would potentially also allow us to have multiple implementations and swap them out by way of feature flags.

My preference is to design the abstract reactor pattern we want, and then if Actix will allow us to facilitate that design then we go with Actix (at least at first, to give us some momentum).

@andynog
Copy link

andynog commented Sep 5, 2019

I like the idea of creating a reactor abstract pattern and use feature flags to swap them out (via compilation using features). The only thing to keep in mind is that if the underline framework doesn't provide all the functionality that you reactor abstract need then you will have to implement them. Ideally the code that will have dependencies on your reactor should not indirectly depend on any features that are specific to the underline framework.

@tarcieri
Copy link
Contributor

tarcieri commented Sep 5, 2019

With Futures (and soon async/await) you should be able to implement most things in a way which is agnostic to the underlying reactor.

If you can do that, you could do neat things like deterministic simulation testing.

@thanethomson
Copy link
Contributor Author

If you can do that, you could do neat things like deterministic simulation testing.

Yeah it'd be incredible if we could do this sort of simulation-based testing!

@davebryson
Copy link

Riker might be interesting to look into. I haven't personally used it yet, but it may at the least have some useful ideas. The 'self-healing/supervisor' feature (like Erlang) would be a nice addition

@thanethomson
Copy link
Contributor Author

Riker might be interesting to look into. I haven't personally used it yet, but it may at the least have some useful ideas. The 'self-healing/supervisor' feature (like Erlang) would be a nice addition

Riker does look pretty cool, and quite simple. Will check it out!

@miketang84
Copy link

async-std might be good option for low reactor.

@ebuchman ebuchman added the structure High level repo-wide structural concerns label Jun 3, 2020
@brapse
Copy link
Contributor

brapse commented Jul 2, 2020

The first iteration of this was done in #302. Obviously there will be more detailed work done when we actually have a p2p layer. But we seemed to have moved on from the questions in this issue. Closing for now. ✌️

@brapse brapse closed this as completed Jul 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
structure High level repo-wide structural concerns
Projects
None yet
Development

No branches or pull requests

7 participants