Does Os X Have an Equivalent to /Dev/Shm

What is the /dev/shm equivalence in Windows System?

If I understood it correctly (based on this post) what you are looking for is Memory Mapped Files.

Create Large File in /dev/shm in parallel: performance

The fastest way to do this is to just call truncate() or ftruncate() to expand the file to the size you want.

You can then mmap() the file into the process's memory space, and have each thread write its section into the mapped area.

Why may /dev/shm folder be periodically cleaned in Ubuntu 18.04?

Look here:

superuser.com: Why are the contents of /dev/shm/ is being removed automatically

Ask Ubuntu: 16.04 LTS and /dev/shm/ Files Disappearing

After hours of searching and reading, I found the culprit. It's a
setting for systemd. The /etc/systemd/logind.conf contains default
configuration options, with each of them commented out. The RemoveIPC
option is set to yes by default. That option tells systemd to clean up
interprocess communication (IPC) for "user accounts" who aren't logged
in. This does not affect "system accounts"

In my case, the files and directories were being created for a user
account, not a system account.

There are two possible solutions:

1. Create the files with/for a system user -- a user created with the system option (adduser -r or adduser --system)

2. Edit /etc/systemd/logind.conf, uncomment the line RemoveIPC=yes, change it to RemoveIPC=no, save, and reboot the system

In my case, I went with option #2 because the user was already
created.

Why use shm_open?

If you open and mmap() a regular file, data will end up in that file.

If you just need to share a memory region, without the need to persist the data, which incurs extra I/O overhead, use shm_open().

Such a memory region would also allow you to store other kinds of objects such as mutexes or semaphores, which you can't store in a mmap()'ed regular file on most systems.

Is there anything like shm_open() without filename?

A library to solve the problem

I managed to write a library that provides the simple interface:

int shm_open_anon(void);

The library compiles without warnings and successfully runs a test program on Linux, Solaris, MacOS, FreeBSD, OpenBSD, NetBSD, DragonFlyBSD and Haiku. You may be able to adapt it to other operating systems; please send a pull request if you do.

The library returns a file descriptor with the close-on-exec flag set. You can clear that flag using fcntl() on all supported operating systems, which will allow you to pass the fd over exec(). The test program demonstrates that this works.

Implementation techniques used in the library

The readme of the library has very precise notes on what was done and what wasn't done for each OS. Here's a summary of the main stuff.

There are several non-portable things that are more or less equivalent to shm_open() without a filename:

• FreeBSD can take SHM_ANON as the pathname for shm_open() since 2008.

• Linux has a memfd_create() system call since kernel version 3.17.

• Earlier versions of Linux can use mkostemp(name, O_CLOEXEC | O_TMPFILE) where name is something like /dev/shm/XXXXXX. Note that we are not using shm_open() at all here -- mkostemp() is implicitly using a perfectly ordinary open() call. Linux mounts a special memory-backed file system in /dev/shm but some distros use /run/shm instead so there are pitfalls here. And you still have to shm_unlink() the temp file.

• OpenBSD has a shm_mkstemp() call since release 5.4. You still have to shm_unlink() the temp file but at least it is easy to create safely.

For other OSes, I did the following:

1. Figure out an OS-dependent format for the name argument of POSIX shm_open(). Please note that there is no name you can pass that is absolutely portable. For example, NetBSD and DragonFlyBSD have conflicting demands about slashes in the name. This applies even if your goal is to use a named shm object (for which the POSIX API was designed) instead of an anonymous one (as we are doing here).

2. Append some random letters and numbers to the name (by reading from /dev/random). This is basically what mktemp() does, except we don't check whether our random name exists in the file system. The interpretation of the name argument varies wildly so there's no reasonable way to portably map it to an actual filename. Also Solaris doesn't always provide mktemp(). For all practical purposes, the randomness we put in will ensure a unique name for the fraction of a second that we need it.

3. Open the shm object with that name via shm_open(name, O_RDWR | O_CREAT | O_EXCL | O_NOFOLLOW, 0600). In the astronomical chance that our random filename already exists, O_EXCL will cause this call to fail anyway, so no harm done. The 0600 permissions (owner read-write) are necessary on some systems instead of blank 0 permissions.

4. Immediately call shm_unlink() to get rid of the random name. The file descriptor remains for our use.

This technique is not quaranteed to work by POSIX, but:

1. The shm_open() name argument is underspecified by POSIX so nothing else is guaranteed to work either.
2. I'll let the above compatibility list speak for itself.

Enjoy.

Why use SysV or POSIX shared memory vs mmap()?

If you have a parent/child relationship, it's perfectly fine to use mmap.

sysv_shm is the original unix implementation that allows related and unrelated processes to share memory. posix_shm standardized shared memory.

If you're on posix system without mmap, you'd use posix_shm. If you're on a unix without posix_shm you'd use sysv_shm. If you only need to share memory vs a parent/child you'd use mmap if available.

---

Related Topics