-
Notifications
You must be signed in to change notification settings - Fork 118
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
[x/programs] Add Engine and Store abstractions #657
Conversation
Signed-off-by: Sam Batschelet <[email protected]>
Signed-off-by: Sam Batschelet <[email protected]>
Signed-off-by: Sam Batschelet <[email protected]>
Signed-off-by: Sam Batschelet <[email protected]>
Will this make a difference in the way programs should be written? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks really good, the abstractions are real nice. Some comments about using inner
and Inner()
and a comment about bulk memory support otherwise lgtm
not this PR no |
Signed-off-by: Sam Batschelet <[email protected]>
Signed-off-by: Sam Batschelet <[email protected]>
Signed-off-by: Sam Batschelet <[email protected]>
This PR adds new types
Engine
andStore
and also migrates theMeter
out of runtime. This PR is one of many which will move towards owning our own types and having the runtime be a simple implementation of these types[1]. This PR also greatly simplifies the runtime.Config giving it basic configurations which affect the runtime implementation. The rest of the config is now directly part of theEngine
. In the context of a VM a single engine should be used for the lifetime of the program. Very similar to a gRPC client. I hope to have the time to implement this as an example into the simulator.In the previous implementation there was a 1:1 relationship between the
Engine
and theStore
. But as each engine can have multiple stores we can reuse the engine in circumstances where we are making program to program calls. The allows us to have more fine grained controls on all of the stores with regards to termination. As a using Stop on a single engine will terminate all child stores.[1] #631