Diogo Flores <dxflo...@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 <rep...@bugs.python.org> <https://bugs.python.org/issue39959> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
