[issue39959] (Possible) bug on multiprocessing.shared_memory
Diogo Flores
report at bugs.python.org
Tue Mar 17 17:43:19 EDT 2020
Diogo Flores <dxflores at outlook.com> added the comment:
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.
#----------------------------------------------------
# https://github.com/python/cpython/blob/master/Lib/multiprocessing/shared_memory.py#L116
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,
Diogo
----------
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39959>
_______________________________________
More information about the Python-bugs-list
mailing list