README.md

title	Inter-process communication

How to compile

Compile me with:

pandoc --standalone --to=revealjs --output=README.html README.md --slide-level=2

Objectives

• Mostly OS primitives
• A few programming models
• When to use each?
• Take only 35 mins

What are processes?

::: {.incremental}

• How to launch processes?
• fork()
• → clone() A fork in the road

:::

Two paradigms

• Explicit == message passing
• Implicit == ? [shared memory]{.fragment}

Shared memory in Linux

::: {.incremental}

• Use threads
• Mmapped file
• POSIX shared memory
  • man shm_overview
• Sys V shared memory
  • man sysvipc

:::

Details on POSIX shm

• Mmapped file: open, mmap, ..., munmap, close
• Incurs I/O overhead eventually

Details on POSIX shm

• shm_open, ftruncate, mmap, ..., munmap, close, shm_unlink
• /dev/shm
• Real world ex in fsatrace

How does POSIX shared memory work?

[What about threads?]{.fragment}

Concerns

::: {.incremental}

• Both threads and POSIX shm
  • Race conditions!
    • Synchronization
• POSIX shm
  • Shm could mmapped to different address!
    • Wrong: *p = target;Right: *p = target - baseaddr;
  • Globally unique keys?
  • Pointers may be pointing outside of shm

:::

Msg Passing

::: {.incremental}

• Pipes
  • man pipe
• FIFOs (aka "named pipes")
  • man mkfifo
• Socket (UNIX, TCP, UDP)
  • man socket(7)
• POSIX message queue
  • man mq_overview
• Sys V message queue
  • man sysvipc :::

Pipes/FIFOs

• Pipes: pipe() and fork() (inherit fds)
  • Must be "related" procs
  • Each proc must close one end!
  • Real world ex in benchexec
• FIFOs: mkfifo(name)
  • Uses normal POSIX FS
  • Real world ex in Zsh

Pipes in your shell

Pipes/FIFOs

::: {.incremental}

• Sequential (unlike random-access mmap)
• Finite capacity
  • Why?
  • Backpressure
• Blocking/non-blocking
• Versus file?

:::

POSIX MQ

• mq_open(), mq_send()/mq_recv(), mq_unlink()
• Sequential
• Finite capacity
• Blocking/non-blocking

Sockets

• Server: [socket(), ]{.fragment} [bind(), ]{.fragmet} [listen(),]{.fragment} [accept(),]{.fragment} [..., ]{.fragment} [close()]{.fragment}
• Client: [socket(),]{.fragment} [connect(),]{.fragment} [...,]{.fragment} [close()]{.fragment}
• Address: UNIX domain, IPv4, or IPv6
• Type: Stream, datagram, sequential packet
• Single server, multiple clients
• Directionality? [Bidirectional]{.fragment}
• Capacity? [Infinite]{.fragment}
• Blockingness? [Non-blocking]{.fragment}

Discussion

File descriptors

::: {.incremental}

• Q: Why do POSIX facilities (shm_open, mq_open, connect, accept) return file descriptors?
• A: e/poll() andselect() use FDs (non-blocking)
• So stay away from SysV facilities!

:::

Shared memory == message passing

::: {.incremental}

• Hitting RAM is slow, so cores have caches
• How to know if another core changed something?
• Cache coherence protocol
  • Cores actually do exchange messages!

:::

Internode communication

::: {.incremental}

• Which IPCs support inter-node communication?
• You might think, "only sockets"
• But cache coherence protocols make PGAS possible

:::

Run your DBs on UNIX domain sockets

• OS knows ident of user reading socket (no need for passwd)
• Going to network requires changing address anyway
  • sudo -u nextcloud psql

RPC programming model

• Remote functions
• Remote objects ("sea of objects")

Actor model

::: {.incremental}

• Erlang
• Go lang
  • "don't communicate by sharing memory; share memory by communicating" src
  • still racey

:::

Everything is just TCP

::: {.incremental}

• FIFO? TCP socket
• UNIX socket? TCP socket
• POSIX MQ? Kafka on a TCP socket

:::

Three-layered cake

{width="40%"} {width="40%"}

Three layer cake for shared-memory programming

ILLIXR

Sources

• An introduction to Linux IPC by Micheal Kerrisk
• Example codes