Comment by marklar423
3 months ago
With all this effort required (as the author points out), I start to wonder if a better solution is to communicate via RPC over local sockets.
There will be some overhead, but it might be a wash considering calling over a FFI often involves similar overhead to marshall / unmarshall objects. And the simplicity gains would be massive.
COM [1] was a solution to these problems thirty years ago.
In-process it's just function calls. Cross-process COM has automatic marshalling for standard types ("automation types") or you can define custom marshalling that does whatever you want.
WinRT [2] is a more modern version. It builds on COM and (among other things) provides the basis for the latest UI frameworks in Windows.
[1]: https://en.wikipedia.org/wiki/Component_Object_Model
[2]: https://en.wikipedia.org/wiki/Windows_Runtime
A long time ago I worked on a project where we needed to distribute an in process COM object, so we moved it to DCOM, instantiated multiple instances, and that worked! All in all COM was a fairly pleasant technology. Not really that different than gRPC (e.g. idl vs. proto).
Why over a socket? You could perform the same protocol more efficiently with normal functions in-process. Maybe we need a standard serializing LPC protocol just using the platform ABI. Or maybe this comes down to something like ZeroMQ in-process.
Mostly because sockets are supported by everything today, and they're easy to understand. What you're describing would certainly work but it looks similar to what the OP did in the blog post, with all the complexity it comes with.
The OP doesn’t serialize. My proposal would still serialize as with RPC, but instead of passing the data over a socket, just pass the data as a binary blob over a regular function call.
1 reply →
https://zeromq.org/ -> TIL really cool, thanks for the pointer.