On 08/07/2020 16:17, Lassi Kortela wrote:
>> For performance, it would be good to consider shared-memory
>> communication instead of pipes.  This reduces copying, which is
>> important when trying to get the highest speed.
>
> Shared memory typically requires implementing a locking mechanism, which
> is not fun. The huge win with pipes is that kernels transparently do the
> locking in an extremely well-standardized fashion.

SHM *can* reduce copying, IF the data is allocated in the shared memory
segment to begin with: you can just pass a signal to the recipient that
the data is ready for them to look at.

If you are implementing a general RPC system that looks like "send this
sexpr to that process", you'll be having to build the binary encoding of
the sexpr into the shared memory segment then sending that signal, which
is still a kind of copying. The recipient may then have an interface to
read the data directly from the SHM rather than reading it to construct
Scheme values in the normal heap, but the former is more work and less
"transparent"...

Now, that still reduces copying compared to writing encoded bytes into a
socket and the kernel copies that to the recipient process, but that may
not be the most limiting factor in the pipeline.

(I built an SHM-based message passing system once using lock-free queues
and a mostly-lock-free shared heap to manage storage in the shared
memory area; it was quite good fun but a lot of low-level programming in
x86/powerpc/sparc assembler to get the lock-free stuff right)

So, yeah, we can do SHM, and it'll give a performance boost, but don't
think it's a huge performance boost or that it's not a whole lot of work
:-) I'd say "start with UNIX sockets" (you can route them over TCP as
well which is handy) and add SHM support later!

--
Alaric Snell-Pym   (M7KIT)
http://www.snell-pym.org.uk/alaric/