Message364481
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 |
|
Date |
User |
Action |
Args |
2020-03-17 21:43:19 | dxflores | set | recipients:
+ dxflores, pitrou, davin, jfischer |
2020-03-17 21:43:19 | dxflores | set | messageid: <1584481399.14.0.942525558376.issue39959@roundup.psfhosted.org> |
2020-03-17 21:43:19 | dxflores | link | issue39959 messages |
2020-03-17 21:43:19 | dxflores | create | |
|