How about using shared-memory to implement ipc-channel.

[lygstate]

Refer to http://doc.qt.io/qt-5/qtcore-ipc-sharedmemory-example.html

[antrik]

Well, for one, ipc-channel actually already offers a mechanism (though quite limited in scope) for dealing with shared memory, which clients are supposed to use explicitly where it makes sense. (When transferring large amounts of data, mostly.) It might be useful to use it automatically (and transparently) for large transfers, to avoid the complexity and overhead of packet splitting -- see #98 for some ideas.

As for using shared memory for IPC in general, that's quite a different story: it's one of these things that actually start looking much less attractive when you consider the details :-) Specifically -- aside perhaps from narrow use cases that can work with lockless data structures -- doing IPC over shared memory still requires issuing system calls, to do synchronisation. For small messages at least, the system calls totally dominate performance -- so if we need to do system calls anyway, we can just as well transfer the actual data directly with them, which is likely to offer better performance. (Since the IPC paths are generally well optimised at the OS level.)

Even for medium-sized messages, using the system mechanisms is probably cheaper. Shared memory might seem attractive, because in theory, you could avoid copying the actual data. That however would require setting up shared memory buffers for every message we want to transfer -- adding extra overhead, which will usually outweigh the saved copy. (Copying memory is in fact a relatively cheap operation, which is pretty hard to beat.) Plus it would make the API more tricky to use. See #126 for some relevant discussion.

Having said all that, I did actually recently ponder the possibility of using a shared memory based mechanism, to improve portability and consistency: the basic mechanism could be the same on all platforms; and porting would boil down to plugging in system-specific primitives for managing shared memory regions and for inter-process locking/synchronisation...

[antrik]

Another important issue is that ipc-channel also needs the ability to send IPC channel endpoints over IPC channels, not just plain data. This seems rather tricky and expensive with a mechanism based on shared memory alone. (I'm not even sure it's possible at all?)

Note that this happens a lot when using a communication style based on remote procedure calls, where every request message carries a distinct channel for the reply. It might be argued that this is not the optimal approach I guess -- but doing otherwise would entail radically different usage patterns...

[l0kod]

FYI, memfd was designed as a safe shared-memory mechanism for Linux. It can be used to share raw data with another process thanks to a file descriptor (which is needed to send IPC channels endpoints over IPC channel). Moreover, memfd support memory sealing which is needed when dealing with untrusted peer (as explained in the man page).

[emilio]

Also see #125.