From 05e922136a3286893bd489a8f2ecfa0dba4da368 Mon Sep 17 00:00:00 2001 From: native-api Date: Sat, 2 Feb 2019 19:22:55 +0300 Subject: [PATCH] bpo-33316: PyThread_release_lock always fails (GH-6541) Use correct interpretation of return value from APIs. --- .../next/Windows/2018-04-20-03-24-07.bpo-33316.9IiJ8J.rst | 1 + Python/thread_nt.h | 5 +++-- 2 files changed, 4 insertions(+), 2 deletions(-) create mode 100644 Misc/NEWS.d/next/Windows/2018-04-20-03-24-07.bpo-33316.9IiJ8J.rst diff --git a/Misc/NEWS.d/next/Windows/2018-04-20-03-24-07.bpo-33316.9IiJ8J.rst b/Misc/NEWS.d/next/Windows/2018-04-20-03-24-07.bpo-33316.9IiJ8J.rst new file mode 100644 index 00000000000..55176791a90 --- /dev/null +++ b/Misc/NEWS.d/next/Windows/2018-04-20-03-24-07.bpo-33316.9IiJ8J.rst @@ -0,0 +1 @@ +PyThread_release_lock always fails diff --git a/Python/thread_nt.h b/Python/thread_nt.h index 21ef5556a6b..fdb192b7d77 100644 --- a/Python/thread_nt.h +++ b/Python/thread_nt.h @@ -104,8 +104,9 @@ LeaveNonRecursiveMutex(PNRMUTEX mutex) if (PyMUTEX_LOCK(&mutex->cs)) return FALSE; mutex->locked = 0; - result = PyCOND_SIGNAL(&mutex->cv); - result &= PyMUTEX_UNLOCK(&mutex->cs); + /* condvar APIs return 0 on success. We need to return TRUE on success. */ + result = !PyCOND_SIGNAL(&mutex->cv); + PyMUTEX_UNLOCK(&mutex->cs); return result; }