←back to thread

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

(www.mpi-hd.mpg.de)
83 points zardinality | 1 comments | 20 Nov 24 13:42 UTC | HN request time: 0.21s | 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(3): >>42196335 #>>42197280 #>>42201053 #
jeffbee ◴[20 Nov 24 17:39 UTC] No.42196335[source]▶
Binder seriously underappreciated, IMHO. But I think it makes sense to use gRPC or something like it if there is any possibility that in the future an "IPC" will become an "RPC" to a foreign host. You don't want to be stuck trying to change an IPC into an RPC if it was foreseeable that it would eventually become remote due to scale.
replies(5): >>42196677 #>>42197248 #>>42198111 #>>42198183 #>>42198692 #
1. dietr1ch ◴[20 Nov 24 19:25 UTC] No.42197248[source]▶
In my mind the abstraction should allow for RPCs and being on the same machine should allow to optimise things a bit, this way you simply build for the general case and lose little to no performance.

Think of the loopback, my programs don't know (or at least shouldn't know) that IPs like 127.0.0.5 are special, but then the kernel knows that messages there are not going to go on any wire and handles that differently.