This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jfischer
Recipients davin, dxflores, jfischer, pitrou
Date 2020-03-16.18:48:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1584384512.24.0.166705106384.issue39959@roundup.psfhosted.org>
In-reply-to
Content
I've run into the same problem. It appears that the SharedMemory class is assuming that all clients of a segment are child processes from a single parent, and that they inherit the same resource_tracker. If you run separate, unrelated processes, you get a separate resource_tracker for each process. Then, when a process does a close() followed by a sys.exit(), the resource tracker detects a leak and unlinks the segment.

In my application, segment names are stored on the local filesystem and a specific process is responsible for unlinking the segment when it is shut down. I was able to get this model to work with the current SharedMemory implementation by having processes which are just doing a close() also call resource_tracker.unregister() directly to prevent their local resource trackers from destroying the segment.

I imagine the documentation needs some discussion of the assumed process model and either: 1) a statement that you need to inherit the resource tracker from a parent process, 2) a blessed way to call the resource tracker to manually unregister, or 3) a way to disable the resource tracker when creating the SharedMemory object.
History
Date User Action Args
2020-03-16 18:48:32jfischersetrecipients: + jfischer, pitrou, davin, dxflores
2020-03-16 18:48:32jfischersetmessageid: <1584384512.24.0.166705106384.issue39959@roundup.psfhosted.org>
2020-03-16 18:48:32jfischerlinkissue39959 messages
2020-03-16 18:48:32jfischercreate