Message414338
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. |
|
Date |
User |
Action |
Args |
2022-03-02 11:25:22 | steve.dower | set | recipients:
+ steve.dower, paul.moore, tim.golden, docs@python, zach.ware, eryksun, ronny-rentner |
2022-03-02 11:25:22 | steve.dower | set | messageid: <1646220322.56.0.267140400377.issue46888@roundup.psfhosted.org> |
2022-03-02 11:25:22 | steve.dower | link | issue46888 messages |
2022-03-02 11:25:22 | steve.dower | create | |
|