Recent Features
| |||||||||||||
Fast IPCFast IPCPosted Sep 16, 2010 23:53 UTC (Thu) by vomlehn (subscriber, #45588)In reply to: Corosync anyone? by cma Parent article: Fast interprocess messaging
Not sure why you wouldn't just use shared memory, which ensures zero copies, and one of a number of synchronization primitives, depending on your particular needs. If not that, then a vmsplice()/splice() variant could be cooked up.
At least at a quick glance, I don't see why any of the other ideas add to the mix.
(Log in to post comments)
Fast IPC Posted Sep 16, 2010 23:56 UTC (Thu) by vomlehn (subscriber, #45588) [Link]
Ah, I get it. The idea is to copy into memory not visible from the other process. Never mind.
Fast IPC Posted Sep 17, 2010 3:09 UTC (Fri) by cma (subscriber, #49905) [Link] Yep ;)The problem is that with this kind of IPC "shared-memory" based it would be possible to code a "self-cotained" app that would not depend on a typical shared-memory which Java native code is not possible to implement (i'm not talking of a JNI based solution). Semophores, locks and so on would not be needed here since with this "new IPC model" we would just stick with file/socket io programming making it possible to obtain really awesome inter-process communication latency and throught put using a unique programming semantics, like async-io on top of NIO, epoll, or even libevent/libev. The trick is that the kernel should be doing all the complex stuff like cache aware, numa etc affinities exposing just what we need, a file descriptor ;) Regards
|
|||||||||||||