Why use the new multiprocessing.shared_memory instead of NamedTemporaryFile(dir=/dev/shm)?

Viewed 210

Another process, not written by me, will have to read the file, so I will have to get the full path somehow. The Python documentation for multiprocessing.shared_memory (SHM) does not mention any way, so this will probably mean using /dev/shm/ as default and asking the user to customize it as necessary.

Since SHM was introduced in Python 3.8, I assume there is some advantage to using this. A disadvantage, however, is that tempfile (docs) automatically cleans up the file whereas with SHM the programmer can forget to.

This is how I would use them (untested/conceptual code):

import os, subprocess, multiprocessing.shared_memory
shm = multiprocessing.shared_memory.SharedMemory(create=True, size=len(mydata))
shm.buf = mydata
path = os.path.join('dev', 'shm', shm.name)
subprocess.run(('tcpdump', '-r', path))
shm.close()
shm.unlink()
import subprocess, tempfile
shm = tempfile.NamedTemporarilyFile(dir='/dev/shm')
shm.write(mydata)
path = shm.name
subprocess.run(('tcpdump', '-r', path))
shm.close()

Given the goal of sharing the memory with other processes (that don't call shm_open(3) but require a filesystem path), it seems hardcoding the path is required anyway. Am I missing some way of retrieving the path from the SHM module, or is this not the intended purpose of the new module and is it supposed to be used differently?

0 Answers
Related