SHM_OPEN(2)

✨ shm_open, shm_unlink — shared memory object operations ✨

okay bestie, we're in the System Calls Manual section of the man pages and this one is literally about shared memory. it's giving "two processes vibing over the same chunk of RAM." 💖

---

🎀 LIBRARY 🎀

Standard C Library (libc, -lc) — yeah she's built right in, no extra linking drama.

---

✨ SYNOPSIS ✨

#include <sys/types.h>
#include <sys/mman.h>
#include <fcntl.h>

int
shm_open(const char *path, int flags, mode_t mode);

int
shm_unlink(const char *path);

---

💅 DESCRIPTION 💅

so shm_open() is a system call that opens a POSIX shared memory object named path — and it can optionally create one too, if you ask nicely. the flags argument is a lil subset of the flags that open(2) takes. you must include an access mode of either O_RDONLY or O_RDWR in flags. periodt. the optional flags O_CREAT, O_EXCL, and O_TRUNC can also come along for the ride.

if O_CREAT is specified, then a brand new shared memory object named path gets created — but only if it doesn't already exist. when that happens, the shared memory object is created with mode mode, subject to the process' umask value. and if you specify both O_CREAT and O_EXCL and a shared memory object named path is already out there living its life, then shm_open() will fail with EEXIST. no cap. 🫶

newly created objects start off with a size of zero — like, empty. nothing. a blank canvas. 🎨 if an existing shared memory object is opened with O_RDWR and the O_TRUNC flag is specified, then the shared memory object gets truncated to a size of zero. the size of the object can be adjusted via ftruncate(2) and queried via fstat(2).

the new descriptor is set to close during execve(2) system calls; see close(2) and fcntl(2).

as a FreeBSD extension, the constant SHM_ANON may be used for the path argument to shm_open(). in this case, an anonymous, unnamed shared memory object is created. since the object has no name, it cannot be removed via a subsequent call to shm_unlink() — it's giving mystery, it's giving no-strings-attached. instead, the shared memory object will be garbage collected when the last reference to the shared memory object is removed. the shared memory object may be shared with other processes by sharing the file descriptor via fork(2) or sendmsg(2). attempting to open an anonymous shared memory object with O_RDONLY will fail with EINVAL. all other flags are ignored. 🙈

and shm_unlink()? that system call removes a shared memory object named path. bye girl 💀

---

🌸 RETURN VALUES 🌸

if everything slays: shm_open() returns a non-negative integer, and shm_unlink() returns zero.

both functions return -1 on failure, and set errno to indicate the error. 😭

---

🦋 COMPATIBILITY 🦋

the path argument does not necessarily represent a pathname (although it does in most other implementations, bestie, don't get confused).

two processes opening the same path are guaranteed to access the same shared memory object if and only if path begins with a slash (/) character.

only the O_RDONLY, O_RDWR, O_CREAT, O_EXCL, and O_TRUNC flags may be used in portable programs. that's the group chat you're allowed to bring.

POSIX specifications state that the result of using open(2), read(2), or write(2) on a shared memory object — or on the descriptor returned by shm_open() — is undefined. like, genuinely undefined, don't do it. however, the FreeBSD kernel implementation explicitly includes support for read(2) and write(2). so it works here, but that's a FreeBSD flex, not a universal truth. 💅

FreeBSD also supports zero-copy transmission of data from shared memory objects with sendfile(2). iconic behavior tbh.

neither shared memory objects nor their contents persist across reboots. they simply do not survive. it's giving fleeting. 🥀

writes do not extend shared memory objects, so ftruncate(2) must be called before any data can be written. see the "EXAMPLES" section below — this is the part that gets people, fr fr.

---

🔥 EXAMPLES 🔥

this example fails without the call to ftruncate(2):

uint8_t buffer[getpagesize()];
ssize_t len;
int fd;

fd = shm_open(SHM_ANON, O_RDWR | O_CREAT, 0600);
if (fd < 0)
    err(EX_OSERR, "%s: shm_open", __func__);
if (ftruncate(fd, getpagesize()) < 0)
    err(EX_IOERR, "%s: ftruncate", __func__);
len = pwrite(fd, buffer, getpagesize(), 0);
if (len < 0)
    err(EX_IOERR, "%s: pwrite", __func__);
if (len != getpagesize())
    errx(EX_IOERR, "%s: pwrite length mismatch", __func__);

see that ftruncate in there? yeah. don't skip her. she's the whole plot. 🫶

---

💀 ERRORS 💀

shm_open() fails with these error codes for these conditions:

• [EINVAL] — a flag other than O_RDONLY, O_RDWR, O_CREAT, O_EXCL, or O_TRUNC was included in flags.
• [EMFILE] — the process has already reached its limit for open file descriptors.
• [ENFILE] — the system file table is full. (not your fault bestie, that's a system-wide situation)
• [EINVAL] — O_RDONLY was specified while creating an anonymous shared memory object via SHM_ANON.
• [EFAULT] — the path argument points outside the process' allocated address space.
• [ENAMETOOLONG] — the entire pathname exceeded 1023 characters.
• [EINVAL] — the path does not begin with a slash (/) character.
• [ENOENT] — O_CREAT is specified and the named shared memory object does not exist.
• [EEXIST] — O_CREAT and O_EXCL are specified and the named shared memory object does exist.
• [EACCES] — the required permissions (for reading or reading and writing) are denied.

shm_unlink() fails with these error codes for these conditions:

• [EFAULT] — the path argument points outside the process' allocated address space.
• [ENAMETOOLONG] — the entire pathname exceeded 1023 characters.
• [ENOENT] — the named shared memory object does not exist.
• [EACCES] — the required permissions are denied. shm_unlink() requires write permission to the shared memory object.

---

👑 SEE ALSO 👑

close(2), fstat(2), ftruncate(2), mmap(2), munmap(2), sendfile(2)

(the whole friend group, go say hi 💜)

---

🌈 STANDARDS 🌈

the shm_open() and shm_unlink() functions are believed to conform to IEEE Std 1003.1b-1993 ("POSIX.1"). "believed to" is doing a lot of heavy lifting in that sentence and I respect it.

---

⭐ HISTORY ⭐

the shm_open() and shm_unlink() functions first appeared in FreeBSD 4.3.

the functions were reimplemented as system calls using shared memory objects directly rather than files in FreeBSD 8.0. glow-up of the century honestly. ✨

---

🍓 AUTHORS 🍓

• Garrett A. Wollman <wollman@FreeBSD.org> — (C library support and this manual page)
• Matthew Dillon <dillon@FreeBSD.org> — (MAP_NOSYNC)

---

and that's the whole page bestie, no notes. 💖

cute lil sign-off: this version of the page comes from Debian and is dated January 20, 2017. mwah, go write some shared memory. 🧚💅