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 dxflores
Recipients davin, dxflores, jfischer, pitrou
Date 2020-03-17.21:43:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Follow up - tested on Linux (The first solution).

The solution presented below will fix the problem with the caveat that the base process (the one that creates the shared-memory obj) must outlive any process that use the shared-memory.
The rationale is that unless *this* process is creating a new shared-memory object (as opposed to attaching itself to an already existing one), then there is no point to register itself to be tracked. By making this small change, the problem I mentioned when I opened this issue disappears.


by changing:

from .resource_tracker import register
register(self._name, "shared_memory")

# To:

if create:
    from .resource_tracker import register
    register(self._name, "shared_memory")


To retain the ability for the base process to be able to exit before those that use the shared-memory obj that the base process itself created (the current/problematic implementation), as well as fix the issue, I suggest the following approach:

When (and only when) a new shared-memory obj is created, such is registered on a new class variable of the resource-tracker, hence it can always be accessed and closed/unlinked by any process later on - this differs from the current approach, where each process that wants to access the shared-memory obj is being registered on the resource-tracker.

I look forward for any discussion on the subject.

Thank you,
Date User Action Args
2020-03-17 21:43:19dxfloressetrecipients: + dxflores, pitrou, davin, jfischer
2020-03-17 21:43:19dxfloressetmessageid: <>
2020-03-17 21:43:19dxfloreslinkissue39959 messages
2020-03-17 21:43:19dxflorescreate