[issue21345] multiprocessing.Pool._handle_workers sleeps too long

Davin Potts added the comment: Despite attempts to reproduce the reported behavior, we don't have anything usable to chase down. It's been 20 months without a response from the OP. There's not much more we can do. -- resolution: -> works for me stage: -> resolved status: pending

[issue21345] multiprocessing.Pool._handle_workers sleeps too long

Changes by Davin Potts : -- status: open -> pending ___ Python tracker ___ ___

[issue21345] multiprocessing.Pool._handle_workers sleeps too long

Changes by Davin Potts pyt...@discontinuity.net: -- nosy: +davin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21345 ___ ___ Python-bugs-list

[issue21345] multiprocessing.Pool._handle_workers sleeps too long

Ofer Schwarz added the comment: I couldn't reproduce this on my machine, but I have no idea if I'm using the wrong sequence of operations, or type of pool, or if my machine is just faster or something else entirely. Johannes, can you upload a repro code for this? -- nosy: +blackfawn

[issue21345] multiprocessing.Pool._handle_workers sleeps too long

R. David Murray added the comment: I'm not that familiar with multiprocessing, but I'd guess it was to avoid burning cpu in a busy-wait (it seems to me that that doesn't matter during finalization, but does during normal running). Maybe it could be changed to an event wait on a shutdown

[issue21345] multiprocessing.Pool._handle_workers sleeps too long

New submission from Johannes Baiter: While testing a module that uses multiprocessing.Pool to distribute load across multiple processes, I noticed that my test suite was copmleting very quickly (~0.15s) on Python 2.6, while Python 2.7 and above took around 10x as long (~1.6s). Upon debugging

[issue21345] multiprocessing.Pool._handle_workers sleeps too long

Changes by Ned Deily n...@acm.org: -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21345 ___ ___ Python-bugs-list mailing list