Hacker News Reader

Comment by jasmer | Hacker News Reader

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.

View on HN

> 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.

Reply on news.ycombinator.com