arrow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Walsh <>
Subject Re: Understanding "shared" memory implications
Date Wed, 16 Mar 2016 14:06:16 GMT
Seems to me IPC/LPC/RPC focuses on the wrong distinction. I think the right
one is between async message-passing (over a socket), where the receiver
decides when to handle the message, and synchronous/direct memory
manipulation (shared mmap, rdma), where the "client" manipulates the
"server's" (rather, shared) memory directly. In the former case, the server
has more gatekeeper-like control over scheduling, and in the latter, the
server may need to poll the shared memory segment in order to know a write
has happened.
On Wed, Mar 16, 2016 at 09:47 Ted Dunning <> wrote:

> On Tue, Mar 15, 2016 at 5:54 PM, Jacques Nadeau <>
> wrote:
> > How do others feel of my redefinition of IPC to mean the same memory
> space
> > communication (either via shared memory or rdma) versus RPC as socket
> based
> > communication?
> >
> IPC already has a strong definition which is close to what you want so it
> isn't so strange.
> On the other hand, you could coin something like LPC (local process
> communication) to contrast with RPC (remote process communication).

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message