> Not conflicting is not a property of parallel binary deployment
I fail to see how starting another process under an OS like Linux or Windows can be conflicting. Don't share resources, and you're conflict-free.
> IPC is, by definition intended to be accessible by other processes
Yes, but you can limit the visibility of the IPC channel to a specific process, in the form of stdin/stdout pipe between processes, which is not shared by any other processes. This is enough of a channel to coordinate creation of a more efficient channel, e.g. a shmem region for high-bandwidth communication, or a Unix ___domain socket (under Linux, you can open a UDS completely outside of the filesystem tree), etc.
A Unix shell is a thing that spawns and communicates with running processes all day long, and I'm yet to hear about any conflicts arising from its normal use.
This seems like an oddly specific take on this topic.
You can get a conflicting resource in a shell by typing 'npm start' twice in two different shells, and it'll fail with 'port in use'.
My point is that you can do not conflicting IPC, but by default IPC is conflicting because it is intended to be.
You cannot bind the same port, semaphore, whatever if someone else is using it. That's the definition of having addressable IPC.
I don't think arguing otherwise is defensible or reasonable.
Having a concern that a network service might bind the same port as an other copy of the same network service deployed on the same target by another host is an entirely reasonable concern.
I think we're getting off into the woods here with an arbitrary 'die on this hill' point about semantics which I really don't care about.
TLDR: If you ship an IPC binary, you have to pay attention to these concerns. Pretending otherwise means you're not doing it properly.
It's not an idle concern; it's a real concern that real actual application developers have to worry about, in real world situations.
I've had to worry about it.
I think it's not unfair to think it's going to be more problematic than the current, very easy, embedded story, and it is a concern that simply does not exist when you embed a library instead of communicating using IPC.
I fail to see how starting another process under an OS like Linux or Windows can be conflicting. Don't share resources, and you're conflict-free.
> IPC is, by definition intended to be accessible by other processes
Yes, but you can limit the visibility of the IPC channel to a specific process, in the form of stdin/stdout pipe between processes, which is not shared by any other processes. This is enough of a channel to coordinate creation of a more efficient channel, e.g. a shmem region for high-bandwidth communication, or a Unix ___domain socket (under Linux, you can open a UDS completely outside of the filesystem tree), etc.
A Unix shell is a thing that spawns and communicates with running processes all day long, and I'm yet to hear about any conflicts arising from its normal use.