Windows: PyThread_release_lock always fails

[native-api]

BPO	33316
Nosy	@pfmoore, @tjguk, @zware, @zooba, @native-api, @miss-islington
PRs	bpo-33316: PyThread_release_lock always fails #6541 [3.7] bpo-33316: PyThread_release_lock always fails (GH-6541) #11737 [3.7] bpo-33316: PyThread_release_lock always fails (GH-6541) #11737 [3.7] bpo-33316: PyThread_release_lock always fails (GH-6541) #11737

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/zooba'
closed_at = <Date 2019-02-02.17:15:27.774>
created_at = <Date 2018-04-20.00:18:55.782>
labels = ['interpreter-core', '3.8', 'type-bug', '3.7', 'OS-windows']
title = 'Windows: PyThread_release_lock always fails'
updated_at = <Date 2019-02-02.17:15:27.774>
user = 'https://github.com/native-api'

bugs.python.org fields:

activity = <Date 2019-02-02.17:15:27.774>
actor = 'steve.dower'
assignee = 'steve.dower'
closed = True
closed_date = <Date 2019-02-02.17:15:27.774>
closer = 'steve.dower'
components = ['Interpreter Core', 'Windows']
creation = <Date 2018-04-20.00:18:55.782>
creator = 'Ivan.Pozdeev'
dependencies = []
files = []
hgrepos = []
issue_num = 33316
keywords = ['patch']
message_count = 7.0
messages = ['315497', '315670', '315714', '316661', '317259', '334751', '334754']
nosy_count = 6.0
nosy_names = ['paul.moore', 'tim.golden', 'zach.ware', 'steve.dower', 'Ivan.Pozdeev', 'miss-islington']
pr_nums = ['6541', '11737', '11737', '11737']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue33316'
versions = ['Python 3.7', 'Python 3.8']

[native-api]

In win7 x64 debug mode with thread_debug=1, every PyThread_release_lock() is accompanied with a message on stderr:

Could not PyThread_release_lock(<id>) error: 0

[zooba]

Looks okay, but I wonder whether the implementation of PyMUTEX_UNLOCK should return something other than zero? What is it meant to return?

[native-api]

In all PyMUTEX_* and most PyCOND_* functions, all the underlying APIs are void. So there's no point for the functions to return anything other than as convention.

A comment at the start of condvar.h says: "APIs generally return 0 on success and non-zero on error".
In Python\ceval_gil.h:57, there are boilerplace checker macros for them
(which will never fire).

So I guess this is done for uniformity.
Regardless, PyMUTEX_UNLOCK and PyMUTEX_LOCK at least are called both with and without checking the return value.

So I would drop the pretense and make these fns void.

---

That said, the reported error still persists after the fix.
The code confusing about which value LeaveNonRecursiveMutex should return on success. Pushed another commit, confirmed to work now.

[native-api]

So I would drop the pretense and make these fns void.

Scratch that. In POSIX, they are #define'd as pthread fns which do return an error code.

So, nothing more to do here.

[native-api]

So, nothing more to do here.

In case that was cryptic, it means: the PR can be acted upon, no other changes are needed.

[zooba]

New changeset 05e9221 by Steve Dower (native-api) in branch 'master':
bpo-33316: PyThread_release_lock always fails (GH-6541)
05e9221

[miss-islington]

New changeset c851dfc by Miss Islington (bot) in branch '3.7':
bpo-33316: PyThread_release_lock always fails (GH-6541)
c851dfc