[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