[issue39959] Bug on multiprocessing.shared_memory

Guido van Rossum added the comment: I declare this a duplicate of issue 38119. -- nosy: +gvanrossum resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> resource tracker destroys shared memory segments when other processes should still have

[issue39959] Bug on multiprocessing.shared_memory

Diogo Flores added the comment: I have tried a different approach using https://gitlab.com/tenzing/shared-array and I got it to perform well on Linux. Basically, the code above places all numpy arrays in /dev/shm which allows you to access and modify them from any number of processes

[issue39959] Bug on multiprocessing.shared_memory

Vinay Sharma added the comment: @rauanargyn , persist flag won't be good idea because it cannot be supported for windows easily, since windows uses a reference counting mechanism to keep track of shared memory and frees it as soon as all the processes using it are done. --

[issue39959] Bug on multiprocessing.shared_memory

Vinay Sharma added the comment: Hi, shared_memory has lot of issues which are mainly being caused due to resource tracking. Initially resource tracking was implemented to keep track of semaphores only, but for some reason resource tracker also started to keep track of shared_memory. This

[issue39959] Bug on multiprocessing.shared_memory

David Parks added the comment: Having a flag seems like a good solution to me. I've also encountered this issue and posted on stack overflow about it here: https://stackoverflow.com/questions/62748654/python-3-8-shared-memory-resource-tracker-producing-unexpected-warnings-at-appli

[issue39959] Bug on multiprocessing.shared_memory

Rauan Mukhamejanov added the comment: Not sure about "it can always be accessed and closed/unlinked by any process later on", as each process will be spawning its own resource_tracker, using a separate pipe. Thus, unregister calls from other processes will not have any effect. The

[issue39959] Bug on multiprocessing.shared_memory

Change by Roundup Robot : -- keywords: +patch nosy: +python-dev nosy_count: 5.0 -> 6.0 pull_requests: +19441 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20136 ___ Python tracker

[issue39959] Bug on multiprocessing.shared_memory

Floris added the comment: I confirm the same issue as Diogo. The provided workaround of unregistering the sharedmemory segment in the 'consuming' process, as suggested by Jeff, solves the issue where exiting the consuming process causes the tracker to incorrectly free the shared memory.

[issue39959] Bug on multiprocessing.shared_memory

Diogo Flores added the comment: Any update on this issue? -- title: (Possible) bug on multiprocessing.shared_memory -> Bug on multiprocessing.shared_memory ___ Python tracker