[zbentley]

> Shared memory works as a transport if you either assume that all parties are trusted (in which case why do IPC in the first place? Just put them in a monolith)

There are all sorts of domains where mutually-trusted parties need IPC. Off the top of my head and in no particular order:

- Applications that pass validated data to/from captive subprocesses. Not everything is available as a natively-linked library. Not every language's natively-linked libraries are as convenient to reliably install as external binaries.

- Parallelism/server systems farming work out to forked (but not exec'd) subprocesses. Not everything needs setuid. Somtimes you just want to parallelize number crunching without the headache of threads (or are on a platform like Python which limits threads' usefulness).

- Replatforming/language transitions in data-intensive applications. Running the new runtime/platform in the same address space as the legacy platform can bring some hairy complexity, which is sidestepped (especially given the temporary-ness of the transitional state) with careful use of shared memory.

And aren't systems like Postgres counterpoints to your claim? My memory isn't the greatest, but IIRC postgres's server-side connections are subprocesses which interact with the postmaster via shared memory, no?

[fefe23]

If you use shared memory with a captive process, that process can probably hack you if it gets taken over by an attacker.

I agree with your parallelism counter-argument in principle. However even there it would probably make sense to not trust each other, to limit the blast radius of successful attacks.

In your next point the "careful" illustrates exactly my point. Using shared memory for IPC is like using C or C++ and saying "well I'll be careful then". It can work but it will be very dangerous and most likely there will be security issues. You are much better off not doing it.

Postgres is a beautiful argument in that respect. Yes you can write a database in C or C++ and have it use shared memory. It's just not recommended because you need professionals of the caliber of the Postgres people to pull it off. I understand many organizations think they have those. I don't think they actually do though.

[zbentley]

> Using shared memory for IPC is like using C or C++ and saying "well I'll be careful then"

Sort of. In the replatforming/codebase conversion case, the amount of care and labor needed to effectively use shared memory for communication is, in my experience, much less than the care and labor needed to make things work in the same address space (and the labor and cost-in-currency of making things work with sufficient performance using traditional IPC is also often preventative). In that regard, I don't think it's equivalent to arguing in favor of C: capable alternatives to C exist that require less care and labor to use; capable alternatives to shared memory IPC in some cases do not.

I'd be curious how much effort and specific shared-memory-IPC-expertise is required on the part of the Postgres maintainers to keep the shared memory layer capable and secure. I hope it's more like iceoryx2 bills itself in that it's relatively well encapsulated such that folks can use it safely without extensive familiarity with the risk domain, but I might be disappointed.

Regardless, I hope we can agree to disagree on specifics; I appreciate the thoughtful response in any case.

[anarazel]

> I'd be curious how much effort and specific shared-memory-IPC-expertise is required on the part of the Postgres maintainers to keep the shared memory layer capable and secure.

I don't think security plays a huge role for shared memory in postgres - if an attacker gains arbitrary code execution in one postgres backend, the installation is hosed. No need to go through SHM to escalate to other backends, there's easier ways.

WRT capable: There's definitely substantial costs due to using inter-process shared memory. But it's more an architectural cost, rather than something that everyone has to bear while just doing mostly unrelated hacking. Some features get harder, less flexible and require more code.

FWIW, there's some work towards moving towards a threaded connection model. Still some way to go, but I expect it to happen eventually.