3 ms·

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 tha

by jasmer 4y ago

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.

eqvinox 4y ago
> 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.
sakras 4y ago
> 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?
- deleted 4y ago
  [deleted]
- jasmer 4y ago
  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.
  - sakras 4y ago
    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.
Spivak 4y ago
Which is how dbus and the efforts to get it in the kernel were born.

by jasmer 4y ago

eqvinox 4y ago

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

sakras 4y ago

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

deleted 4y ago
[deleted]
jasmer 4y ago
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.
- sakras 4y ago
  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.

Spivak 4y ago

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