←back to thread

121 points zardinality | 1 comments | | HN request time: 0.258s | source
Show context
pjmlp ◴[] No.42195953[source]
> Using a full-featured RPC framework for IPC seems like overkill when the processes run on the same machine.

That is exactly what COM/WinRT, XPC, Android Binder, D-BUS are.

Naturally they have several optimisations for local execution.

replies(4): >>42196335 #>>42197280 #>>42201053 #>>42209092 #
merb ◴[] No.42197280[source]
Btw. Modern windows also superports Unix domain sockets, so if you have an app that has another service that will run on the same machine or on a different one it is not so bad to use grpc over uds.
replies(1): >>42197431 #
pjmlp ◴[] No.42197431[source]
Nice idea, although it is still slower than COM.

COM can run over the network (DCOM), inside the same computer on its own process (out-proc), inside the client (in-proc), designed for in-proc but running as out-proc (COM host).

So for max performance, with the caveat of possibly damaging the host, in-proc will do it, and be faster than any kind of sockets.

replies(3): >>42197698 #>>42202005 #>>42202658 #
merb ◴[] No.42202005[source]
Well if you need ipc to connect different languages, you will stay away from COM. Heck once you use anything but rust,c or c++ you should drop com. Even dotnet support for com is aweful. And if you ever written a outlook addin, than you will start hating com by yourself, thanks to god that Microsoft is going away from that
replies(2): >>42204263 #>>42205125 #
1. p_l ◴[] No.42204263[source]
All new Windows API for over a decade are shipped as COM, iirc.

And COM ability to run in separate process is one of the things that makes it easier to run with different languages in my experience. Once you got over the hurdle of supporting COM, especially if you had support for type libraries and introspection-less COM, it was home free. Meanwhile I'm wary of dealing with a C++ library even if writing in C++