
Robust Interprocess Locks - squadrick
https://squadrick.github.io/journal/ipc-locks.html
======
wahern
> It keeps track of PID of the last process that acquired it, and if another
> process can’t acquire it, it can check if the PID is still alive using stat,
> if it’s dead it will unlock the mutex and reset the field of previous owner.

That's not safe. PIDs are recycled.

The only correct solution I can think of is to place the lock in shared
memory, use the futex(2) API, and use set_robust_list
([https://linux.die.net/man/2/set_robust_list](https://linux.die.net/man/2/set_robust_list))
to ensure the kernel will unlock a futex if a process dies.

You _may_ (should?) be able to initialize a pthread-based
PTHREAD_PROCESS_SHARED + PTHREAD_MUTEX_ROBUST mutex in a shared memory region
and have everything just work.

~~~
wbl
POSIX shmem is a bit more portable, and flock definitely will do the job.
Futex is a linuxism.

------
ridiculous_fish
How do others do publish-subscribe architecture on Linux? There's no multicast
IPC primitives, and nothing like the Mac's lovely notify(3).

One disgusting technique is to use a file descriptor's "ready" state as a
signal. Wait until the fd is readable, then check the shared memory for new
data. Surely there's better.

~~~
woodruffw
> How do others do publish-subscribe architecture on Linux?

One great (read: terrible) hack is to do signal delivery on process groups.

I know a multicast AF_UNIX patch for Linux has been floating around for years,
but I have no idea if it's ever landed in a mainstream kernel.

My go-to for pseudo-multicast on POSIX/Linux is shared memory + semaphores.

