Corosync anyone? [LWN.net]

Corosync anyone?

Posted Sep 16, 2010 21:17 UTC (Thu) by cma (subscriber, #49905)
Parent article: Fast interprocess messaging

And why not implement something like corosync (http://www.kernel.org/doc/ols/2009/ols2009-pages-61-68.pdf) focusing on performance and scalability?

I mean, it would be great to have an very scalable Linux IPC with file I/O semantics. It would be very nice to abstract a "shared memory" like IPC using async-io back-ends with syscalls like epoll, or even using libevent or libev on top of.

I'm very interested in making a Java based app talk with very low latencies with a C/C++ app via NIO on Java's side and libevent/libev on C/C++ side. The point is that no TCP stack (or UNIX sockets) would be used, instead a memory area mapped to a "file descriptor" hook on both sides (Java and C/C++). Is that possible?

Any thoughts/ideas?

(Log in to post comments)

Fast IPC

Posted Sep 16, 2010 23:53 UTC (Thu) by vomlehn (subscriber, #45588) [Link]

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.

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

Corosync anyone?

Posted Sep 18, 2010 6:19 UTC (Sat) by njs (guest, #40338) [Link]

> a memory area mapped to a "file descriptor" hook on both sides

I think this is the precise definition of the word "pipe"?