[issue29871] Enable optimized locks on Windows

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29871] Enable optimized locks on Windows

Change by Paulie Pena : -- nosy: +paulie4 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29871] Enable optimized locks on Windows

Steve Dower added the comment: > I assume you meant #35662 Yes indeed. I am apparently massively dyslexic when it comes to copying issue numbers into the bpo comment field :) Meanwhile, over on #35662, Jeff has a fix for at least one of the regressions. -- versions: +Python 3.8

[issue29871] Enable optimized locks on Windows

Josh Rosenberg added the comment: I assume you meant #35662 (based on the superseder note in the history). -- ___ Python tracker ___

[issue29871] Enable optimized locks on Windows

Steve Dower added the comment: On issue 35562 Jeff posted a deeper analysis of the issue in TIMEDWAIT. That will need fixing along with the other regressions before we can enable these. -- nosy: +je...@livedata.com ___ Python tracker

[issue29871] Enable optimized locks on Windows

Change by Alexey Izbyshev : -- nosy: +izbyshev ___ Python tracker ___ ___

[issue29871] Enable optimized locks on Windows

STINNER Victor added the comment: FYI I proposed a PR which removes the emulation of condition variable: https://github.com/python/cpython/pull/5231 This PR removes code specific to Windows Vista: see bpo-32592. -- nosy: +vstinner

[issue29871] Enable optimized locks on Windows

Steve Dower added the comment: I updated the PR to be mergeable and let the AppVeyor run work - https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.2452 Unfortunately, there appear to be a number of regressions due to this. I'm not going to have time right now to work through them

[issue29871] Enable optimized locks on Windows

Kristján Valur Jónsson added the comment: Hi there. Looking at the API docs today (https://msdn.microsoft.com/en-us/library/windows/desktop/ms686304(v=vs.85).aspx) it appears that the timeout case is documented. I'm fairly sure that it wasn't when I implemented it. There was a good reason for

[issue29871] Enable optimized locks on Windows

Josh Rosenberg added the comment: Hmm... I was only running the threading related tests originally, and they passed, but it looks like this causes problems with multiprocessing (test_multiprocessing_spawn and test_concurrent_futures both stall out forever with this change, with or without my

[issue29871] Enable optimized locks on Windows

Josh Rosenberg added the comment: Note: Beyond turning on the new primitives by default, I also made a change to PyCOND_TIMEDWAIT. The original code looked wrong, in that: 1. It assumed that when SleepConditionVariableSRW returned non-zero, you didn't know if the wait had timed out or not, so

[issue29871] Enable optimized locks on Windows

Changes by Josh Rosenberg : -- pull_requests: +670 ___ Python tracker ___ ___

[issue29871] Enable optimized locks on Windows

New submission from Josh Rosenberg: Kristjan wrote improved locking primitives in #15038 that use the new (in Vista) SRWLock and Condition Variable APIs. SRWLocks (used in exclusive mode only) replace Critical Sections, which is slower than SRWLock and provides no features we use that might