←back to thread

Using gRPC for (local) inter-process communication (2021)

(www.mpi-hd.mpg.de)
121 points zardinality | 3 comments | 20 Nov 24 13:42 UTC | HN request time: 0.804s | source
Show context
pjmlp ◴[20 Nov 24 17:04 UTC] 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 ◴[20 Nov 24 19:30 UTC] 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 ◴[20 Nov 24 19:49 UTC] 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 ◴[21 Nov 24 07:38 UTC] 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. pjmlp ◴[21 Nov 24 15:18 UTC] No.42205125[source]▶
Good luck with that goal, after Longhorn went down, all its design ideas were resurfaced as COM, and since Vista, COM (alongside with its WinRT makeover), is the main API model in Windows.

Raw Win32 C API is stuck in Windows XP view of the world, with a few exceptions in some subsystems.

Yes COM tooling sucks, which is kind of sad given that it is the main API model in modern Windows, but I guess WinDev suffers from Stockhold syndrome.

AddIns are only moving away from COM, because otherwise they wouldn't work in your browser, so you get to use JavaScript and TypeScript instead, and on native Office they run inside a Webwidget, hurray for performance.

replies(1): >>42211096 #
2. fulladder ◴[22 Nov 24 04:07 UTC] No.42211096[source]▶
I think I remember learning COM object programming in the late 1990s, and Longhorn would still have been an active project at that time. Been a long time, though, so maybe I'm mistaken.
replies(1): >>42211581 #
3. pjmlp ◴[22 Nov 24 06:23 UTC] No.42211581[source]▶
Yes, and?

COM history traces back to OLE, introduced in Windows 3.0 replacing DDE.

.NET was designed as COM replacement, however the way things went down was something else.