Hacker News Reader

Comment by jasmer | Hacker News Reader

I really disagree with the sockets bit. Sockets are designed for networking, with a particular focus on IP. Not IPC.

I for one think that the 'absurd thing' is that IPC is not built into OS as a core feature. That, and process isolation. Both sockets and shared memory are quite problematic and the challenge of 'true IPC' that works nicely with threads etc. is real.

View on HN

> IPC is not built into OS as a core feature

POSIX and its derivatives build IPC into the OS as a core feature. In particular, POSIX is built around memory mappings and file descriptor inheritance, which means it is extraordinarily easy to make processes communicate.

I honestly have no idea what you mean by this statement.

Unix domain sockets are (1) fast, (2) primitive (just a file), (3) widely available, and (4) can be used between multiple processes extremely easily (use SOCK_DGRAM).

I honestly have no idea why someone would think that Sockets, which are designed for IP networking are an ideal solution for IPC, or why someone would think that 'shared memory' is sufficient for sharing information when it's really only part of a solution.

If it were easy than everyone would be doing it the same way and there wouldn't be a discussion about it.

With shared memory in particular, the issue gets tricky around signalling and locking aka indicating to other processes when new info is available, and when another process is accessing the data.

If anyone took just a moment to design an API that was user/developer centric, and worked back from there, it would look materially different from what is provided today.

> Sockets, which are designed for IP networking

Sockets aren't designed for IP networking. They date back to a time when it wasn't even clear TCP/IP would win vs. IPX/SPX. Or DECnet. AF_UNIX sockets have things that IP sockets can't even dream of doing (the very poorly named SCM_RIGHTS). And sockets don't really cover IP networking all that well, e.g. MPTCP and SCTP shenanigans to get multi-address & multi-stream connections.

That said, both sockets and mmap are low-level APIs. A higher level "user/developer centric" API indeed looks different.

> With shared memory in particular, the issue gets tricky around signalling and locking aka indicating to other processes when new info is available, and when another process is accessing the data.

POSIX has mutex and condition variable, is this not enough to do those things?

As far as I know mutex is not a signal that data is received, which would require some kind of threading / interrupt.

Moreover, it's a bit of a secondary thing.

The API would look something like a call function with a receive function/lambda on the receiving side, with memory possibly being 'handed over' or whatever. And so the level of abstraction would be slightly higher.

And it would be a no-brainer, well established thing. Searching for how to do that today and it's always complicated.

I’m afraid I don’t understand. If you want one process to signal to another that data is available, you have the receiver block on a condition variable. When the sender writes its data it signals the condition variable. This is all handled by the kernel, no signal/interrupt is required. Or if you don’t want blocking, you can have a shared ring buffer, with the two processes interacting with it atomically.

Which is how dbus and the efforts to get it in the kernel were born.

unix domain sockets are designed to be used entirely locally.

and files are one-way sockets. They lied when they said "everything is a file", but it's almost true that (for Posix) "everything is a handle."

Win32 is POSIX! => "everything is a handle."

Reply on news.ycombinator.com