[ESI Runtime] Replace Cap'nProto with gRPC #7217
Conversation
After spending a truely obnoxious amount of time fighting capnp and libkj, we made the decision to switch to another RPC system. We're no longer modeling and serializing message types in Capnp and we don't need the performance which capnp/libkj RPC promises, so there's really no need for the additional complexity. A slower system which is thread safe should work fine. This commit breaks the build in a pretty horrible way and is not intended to be merged on its own. It simply breaks up the diff.
MUCH simpler
|
yep. that's what I expected. and that's with a bunch more code documentation. |
There was a problem hiding this comment.
Great to see that the diff in the non-cosim-backend code was relatively minor.
Based on the implementation and testing you've done on this, how is your initial gut feeling for gRPC vs capnproto? I'm thinking both in terms of compile-time and runtime-debugging that you went through.
Actually, it was non-existent!
It was definitely easier to debug both compilation and runtime bugs; BUT, only because I'm more familiar with standard threading systems than libkj's async model. The 'googleability' aspect surprisingly didn't help much (the runtime errors I ran into didn't come up with any relevant results), though the larger number of examples did help. Capnp RPC is more expressive, which I miss. It supports non-unary arguments/results and returning a capability (i.e. API), both of which help model a moderately complex system in a cleaner way. Also, capnp proto doesn't have NEARLY as many complex dependencies which probably would have made a Actually, we would probably still be using capnp if libkj documentation was much better (notably the tour document) years ago when I first started using it and libkj had evolved to use newer C++ APIs instead of sticking with its own stuff (which pre-dated the newer C++ APIs). I just got fed up over the years dealing with libkj and didn't take the time to properly learn it based on the code documentation when I had time at the outset. |
|
Note that the commit message on this is wrong. It does not break the build in a horrible way. I just forgot to remove that part from the message when merging. 🤦 |
After spending a truly obnoxious amount of time fighting capnp and libkj, we made the decision to switch to another RPC system. We're no longer modeling and serializing message types in Capnp and we don't need the performance which capnp/libkj RPC promises, so there's really no need for the additional complexity. A slower system which is thread safe should work fine. This commit breaks the build in a pretty horrible way and is not intended to be merged on its own. It simply breaks up the diff.
gRPC is a lot easier to use owing to Cap'nProto's C++ implementation using likj.
Breaks MMIO, but we're not currently using it.