Refactor feature/proc #94
Conversation
* Pull wazero.Runtime config out of pkg/process; populate via Fx. * Wrap public client capabilities with high-level API types. * Use capnp refcounting to factor out tracking of release funcs.
| msg @1 :Text; | ||
| exitErr :group { | ||
| code @2 :UInt32; | ||
| module @3 :Text; |
There was a problem hiding this comment.
What does module represent?
There was a problem hiding this comment.
Ah, this is the name of the module. It is one of the fields contained in sys.ExitError, which is returned by calls to exported module functions. (Maybe we should rename to moduleName?)
| return err | ||
| } | ||
|
|
||
| ee := state.Err.(*sys.ExitError) |
There was a problem hiding this comment.
Just so we are in the same page, will error be used for when something goes wrong outside the process execution and ExitError for errors raised during execution? If so I like it
There was a problem hiding this comment.
Correct -- returning an error from a capability server's method means "the RPC call failed". The capnp Error struct means "an application-level error occurred". In the present case, that indeed means the guest code returned an error.
This is exactly equivalent to HTTP, where error means the network-level request/response failed, and a status code can indicate an error in the application logic. It's just more expressive than returning integer codes.
@mikelsr As warned, this ended up being a pretty large diff.
Changes include:
process.Servername; let me know what you think).pkg/serverLet me know what you think!
P.S. It might be easier to checkout the
cleanup/proc-lazy-initbranch and just read that directly. The diff is super noisy (though much of it is file renames/deletes). If you decide to do this, running the unit test is probably a good place to start.