Eryk Sun added the comment:
Putting words into action, here's an example of what a privileged process (e.g.
running as SYSTEM) can do if a script or application is written to call the
undocumented NT API function NtMakePermanentObject(). A use case would be a
script running as a system servi
Steve Dower added the comment:
Eryk's post is useful background information, but not helpful for this
particular case ;)
>From Windows's POV, there is no "creating" process of the shared memory. If
>it's going away, it's because none of the other processes are not keeping it
>open - simple
Ronny Rentner added the comment:
Many thanks for your explanation. It makes sense now.
One thing I've learned is that I need to get rid of the resource trackers for
shared memory, so I've applied the monkey patch fix mentioned in
https://bugs.python.org/issue38119
The issue is that you need
Eryk Sun added the comment:
> The persistent mode sounds just like Python shared memory also works
> on Linux (where I can have these /dev/shm/* files even after the
> Python process ends) but I think on Windows, Python is not using
> the persistent mode and thus the shared memory goes away,
Ronny Rentner added the comment:
Thanks for your quick response.
My bigger scope is real time audio and video processing where I use multiple
processes that need to be synchronized. I use shared memory for that.
As a small spin off, I've hacked together a dict that is using shared memory as
Eryk Sun added the comment:
> Yes, named memory mappings only exist on Windows until the last
> reference is closed, so this is a difference due to the underlying OS.
That's true for the Windows API, so it's true for all practical purposes. In
the underlying NT API, creating a permanent ker
Steve Dower added the comment:
Yes, named memory mappings only exist on Windows until the last
reference is closed, so this is a difference due to the underlying OS.
The implementation of unlink() recognises this (the entire body is under
a _USE_POSIX check), but the docs do not reflect it.
New submission from Ronny Rentner :
According to
https://docs.python.org/3/library/multiprocessing.shared_memory.html#multiprocessing.shared_memory.SharedMemory.close
if I call close() on a shared memory, it shall not be destroyed.
Unfortunately this is only true for Linux but not for Windows
