[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Change by Géry : -- nosy: +maggyero ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

timka added the comment: On the long run: Maybe this could solve some win32api problems? https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/ -- nosy: +timka ___ Python tracker

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Change by jdogzz-g5 : -- nosy: +jdogzz-g5 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Change by David Felsen : -- nosy: +davfelsen ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Steve Newcomb added the comment: Sometimes a leak is exactly what's wanted, i.e. a standing block of shared memory that allows sharing processes come and go ad libitum. I mention this because I haven't seen anyone mention it explicitly. While turicas's monkeypatch covers the use case in

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Álvaro Justen added the comment: Based on changes at https://github.com/python/cpython/pull/15989 I've monkey-patched `multiprocessing.resource_tracker` so my current applications (running on Python 3.9.2) won't be affected. The code may be useful to others while the PR is not merged and we

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

keven wang added the comment: Agree w/ PR here to remove resource tracker unlinking as a quick fix: https://github.com/python/cpython/pull/15989 This will at least make the unlink behavior more controllable, which is not the case currently (on mac and linux). Would love to have this

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Change by Vinay Sharma : -- pull_requests: +22087 pull_request: https://github.com/python/cpython/pull/23174 ___ Python tracker ___

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Vinay Sharma added the comment: As suggested by Guido I have floated this solution to python-dev mailing list. Link to archive: https://mail.python.org/archives/list/python-...@python.org/thread/O67CR7QWEOJ7WDAJEBKSY74NQ2C4W3AI/ -- ___ Python

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Damian Barabonkov added the comment: Agreed. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Vinay Sharma added the comment: Well, the chances of resource tracker dying abruptly are very less because it's thoroughly tested, and there are mechanisms to re-spawn resource_tracker process if you see the code. There is a function called `def ensure_running`. Resource tracker is still

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Damian Barabonkov added the comment: Unless the resource_tracker also dies along with the process. In which case, I'm not sure what there is there to do. I believe the resource_tracker actually spawns a process alongside the process that uses it. So if the parent process seg-faults, the

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Vinay Sharma added the comment: That's a valid point Guido. But, I guess this can be easily handled by resource tracker. At this current moment resource tracker unlinks shared memory if the process which created it dies without unliking it. Therefore, resource tracker handles cleaning up

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Guido van Rossum added the comment: I recommend bringing this new proposal up on python-dev or python-ideas, to get more eyeballs on the ideas before attempting implementation. One immediate worry I have is that if the reference counter is maintained in the shared memory segment, every

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Damian Barabonkov added the comment: As per Guido's comment (https://github.com/python/cpython/pull/21516#issuecomment-668110711), I'm going to use this space to discuss ways to go forward with resource tracking and SharedMemory. Taking inspiration from Vinay

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Guido van Rossum added the comment: @Davin, could you merge one or the other of the PRs that fix this? Presumably also backport to 3.9 and 3.8 (but that's up to you and the release manager). -- nosy: +gvanrossum versions: +Python 3.10 ___ Python

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Change by Vinay Sharma : -- pull_requests: +20652 pull_request: https://github.com/python/cpython/pull/21516 ___ Python tracker ___

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Vinay Sharma added the comment: Hi Davin, This PR would fix the issues mentioned by you, by not prematurely unlinking the shared memory segment. And, therefore it would make shared memory useful in a lot of use cases. But, this would still not make Unix's implementation consistent with

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

Change by Davin Potts : -- keywords: +patch pull_requests: +15618 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15989 ___ Python tracker ___

[issue38119] resource tracker destroys shared memory segments when other processes should still have valid access

New submission from Davin Potts : The resource tracker currently destroys (via _posixshmem.shm_unlink) shared memory segments on posix systems when any independently created Python process with a handle on a shared memory segment exits (gracefully or otherwise). This breaks the expected