[issue31092] delicate behaviour of shared (managed) multiprocessing Queues

2017-10-08 Thread Prof Plum
Prof Plum <dwyerf...@gmail.com> added the comment: @Antoine Pitrou >Well... it's called *async* for a reason, so I'm not sure why the behaviour >would be partially synchronous. To a avoid race condition >I'm not sure how. In mp.Pool we don't want to keep references to input

[issue31092] multiprocessing.Manager() race condition

2017-10-05 Thread Prof Plum
Prof Plum <dwyerf...@gmail.com> added the comment: Oh I see, I thought getting an error that caused the python code execution to terminate was considered a "crash". On the note of whether you should fix this I think the answer is yes. When I call pool.apply_async() I expect i

[issue31092] multiprocessing.Manager() race condition

2017-09-21 Thread Prof Plum
Changes by Prof Plum <dwyerf...@gmail.com>: -- title: Potential multiprocessing.Manager() race condition -> multiprocessing.Manager() race condition ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue31092] Potential multiprocessing.Manager() race condition

2017-07-31 Thread Prof Plum
New submission from Prof Plum: So I was writing code that had multiple write thread and read thread "groups" in a single pool (in a group a few write threads write to a queue that a read thread reads), and I ran into what I think is a race condition with the multiprocessing.Manag