[issue23510] multiprocessing bug SyncManager and 'with'

Change by Irit Katriel : -- resolution: duplicate -> out of date ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue23510] multiprocessing bug SyncManager and 'with'

Irit Katriel added the comment: Yes, it was fixed in version 3.3, under issue15064: https://github.com/python/cpython/commit/ac38571f00ccb5e1e0346ad27a8fac96d05e61c3 -- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> Use context manager

[issue23510] multiprocessing bug SyncManager and 'with'

Irit Katriel added the comment: I don't see this problem in python 3.10. Is it a python 2-only issue, and if so then can this issue be closed? Running Release|Win32 interpreter... Python 3.10.0a0 (heads/bpo-24792-dirty:1e183f4de5, Sep 14 2020, 15:53:51) [MSC v.1916 32 bit (Intel)] on win32

[issue23510] multiprocessing bug SyncManager and 'with'

Davin Potts added the comment: I have a working patch that addresses this behavior and tests to go along with it but am still working on updating the docs. Updating the docs in 2.7 in a way to as closely match the docs in 3.4/3.5 as possible seems reasonable. It remains unclear why __enter__

[issue23510] multiprocessing bug SyncManager and 'with'

Cezary Wagner added the comment: Yes it is what is wanted by me and other people I think. 1. enter has not start call. 2. exit has shutdown but it is not supported 3. 'with' is what is need since it is simple to manage Good analysis. -- ___ Python t

[issue23510] multiprocessing bug SyncManager and 'with'

Davin Potts added the comment: A much simpler example of code triggering the described issue: import multiprocessing.managers with multiprocessing.managers.SyncManager() as s: print "here" Running the above code in 2.7.9 results in an exception with the traceback: Tracebac

[issue23510] multiprocessing bug SyncManager and 'with'

Davin Potts added the comment: Successfully reproduced on OS X 10.10 with 2.7.9. Changing the issue type to "behavior" because "crash" is reserved for "Hard crashes of the Python interpreter – possibly with a core dump or a Windows error box." In this issue, we do see an exception get raised