You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using multiprocessing.Manager with concurrent.futures.ProcessPoolExecutor, there is a particular ordering of the context managers that results in multiprocessing.managers.py hanging in the method serve_forever, forever. This can be triggered by raising a KeyboardInterrupt while the child process(es), here something, are busy. The ordering that leads to the bug is: Manager first, then ProcessPoolExecutor inside.
importmultiprocessingfromconcurrent.futuresimportProcessPoolExecutorfromtimeimportsleepdefsomething():
sleep(10)
# Uncomment one of the following blocks### Works correctly:# # Interrupt with CTRL+C while `something` is busy# # Takes just one KeyboardInterrupts to terminate fully# with ProcessPoolExecutor() as executor:# futures = []# with multiprocessing.Manager() as manager:# futures.append(executor.submit(something))## for f in futures:# f.result()### Doesn't work correctly, will hang often, try it a few times:# # Interrupt with CTRL+C while `something` is busy# # Takes one KeyboardInterrupts to get stuck, and another to terminate fully# with multiprocessing.Manager() as manager:# with ProcessPoolExecutor() as executor:# futures = [executor.submit(something)]# # for f in futures:# f.result()
I am not too familiar with the exact inner workings of these two context managers, but as a user, there was at least nothing to make me aware that the 2nd example is bad. If it's not a bug, and just incorrect ordering, perhaps ProcessPoolExecutor could raise an exception or print a warning that it shouldn't be used inside a Manager context in such a way.
CPython versions tested on:
3.9, 3.10, 3.11, 3.12
Operating systems tested on:
Linux
The text was updated successfully, but these errors were encountered:
Bug report
Bug description:
When using multiprocessing.Manager with concurrent.futures.ProcessPoolExecutor, there is a particular ordering of the context managers that results in multiprocessing.managers.py hanging in the method
serve_forever
, forever. This can be triggered by raising a KeyboardInterrupt while the child process(es), heresomething
, are busy. The ordering that leads to the bug is: Manager first, then ProcessPoolExecutor inside.I am not too familiar with the exact inner workings of these two context managers, but as a user, there was at least nothing to make me aware that the 2nd example is bad. If it's not a bug, and just incorrect ordering, perhaps
ProcessPoolExecutor
could raise an exception or print a warning that it shouldn't be used inside aManager
context in such a way.CPython versions tested on:
3.9, 3.10, 3.11, 3.12
Operating systems tested on:
Linux
The text was updated successfully, but these errors were encountered: