Steve Dower <steve.do...@python.org> 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 refcounting. That may be knowledge you can use to work around it. Alternatively, the workaround I suggested in my first post could also help. If the multiprocessing SharedMemory object is critical, you need the extra steps, but if all the processes can receive a filesystem path instead of however they're getting the reference today, you can use a real file with mmap to achieve exactly the same thing. (All that's missing is that SharedMemory won't take an open file object or a path, which is reasonable, but not helpful right here.) Switching this to a documentation bug: we should clarify that unlink() has no effect on Windows and shared memory blocks go away when the last SharedMemory object is close()d. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python versions: +Python 3.11, Python 3.9 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue46888> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
