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 pdgoins-work
Recipients eryksun, neologix, paul.moore, pdgoins-work, pitrou, steve.dower, tim.golden, tim.peters, tupl, vstinner, zach.ware
Date 2018-04-30.21:16:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1525122985.39.0.682650639539.issue21822@psf.upfronthosting.co.za>
In-reply-to
Content
Focusing on the Windows case specifically...  One way to possibly make this work (although perhaps not as clean as may be desired) would be to add polling logic into the thread_nt.h version of PyThread_acquire_lock_timed.

That would have the benefit of avoiding the complexity of the various "non recursive mutex" implementations (i.e. semaphores vs "emulated" condition variables vs native condition variables) and may be less code than setting up "alertable" WaitForObjectSignleObjectEx calls (plus whatever else needs to be done for the SRW-lock-based code path).

Thoughts or feedback?  (I've not done any mainline Python commits yet so I'm totally ready to be completely wrong or misguided here.)
History
Date User Action Args
2018-04-30 21:16:25pdgoins-worksetrecipients: + pdgoins-work, tim.peters, paul.moore, pitrou, vstinner, tim.golden, neologix, zach.ware, eryksun, steve.dower, tupl
2018-04-30 21:16:25pdgoins-worksetmessageid: <1525122985.39.0.682650639539.issue21822@psf.upfronthosting.co.za>
2018-04-30 21:16:25pdgoins-worklinkissue21822 messages
2018-04-30 21:16:25pdgoins-workcreate