This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steve.dower
Recipients bquinlan, diogocp, paul.moore, sbt, steve.dower, terry.reedy, tim.golden, tim.peters, zach.ware
Date 2016-05-09.16:15:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> Some quick Googling strongly suggests there's no reasonably general way to overcome the Windows-defined MAXIMUM_WAIT_OBJECTS=64 for implementations that call the Windows WaitForMultipleObjects().

The recommended way to deal with this is to spin up threads to do the wait (which sounds horribly inefficient, but threads on Windows are cheap, especially if they are waiting on kernel objects), and then wait on each thread.

Personally I think it'd be fine to make the _winapi module do that transparently for WaitForMultipleObjects, as it's complicated to get right (you need to ensure you map back to the original handle, timeouts and cancellation get complicated, there are real race conditions (mainly for auto-reset events), etc.), but in all circumstances it's better than just failing immediately. Handling it within multiprocessing isn't a bad idea, but won't help other users.

I'd love to write the code to do it, but I doubt I'll get time (especially since I'm missing the PyCon US sprints this year). Happy to help someone else through it. We're going to see Python being used on more and more multicore systems over time, where this will become a genuine issue.
Date User Action Args
2016-05-09 16:15:50steve.dowersetrecipients: + steve.dower, tim.peters, terry.reedy, paul.moore, bquinlan, tim.golden, sbt, zach.ware, diogocp
2016-05-09 16:15:50steve.dowersetmessageid: <>
2016-05-09 16:15:50steve.dowerlinkissue26903 messages
2016-05-09 16:15:49steve.dowercreate