[issue3001] RLock's are SLOW

[STINNER Victor]

STINNER Victor <victor.stinner at haypocalc.com> added the comment:

rlock_acquire_doc: "(...) return None once the lock is acquired".
That's wrong, acquire() always return a boolean (True or False).

rlock_release(): Is the assert(self->rlock_count > 0); really required?
You're checking its value few lines before.

rlock_acquire_restore(): raise an error if the lock acquire failed,
whereas rlock_acquire() doesn't. Why not raising an error in
rlock_acquire() (especially if blocking is True)? Or if the error can
never occur, remove the error checking in rlock_acquire_restore().

rlock_acquire_restore(): (maybe) set owner to 0 if count is 0.

rlock_release_save(): may also reset self->rlock_owner to 0, as
rlock_release().

rlock_new(): why not reusing type instead of Py_TYPE(self) in
"Py_TYPE(self)->tp_free(self)"?

__exit__: rlock_release() is defined as __exit__() with METH_VARARGS,
but it has no argument. Can it be a problem?

Anything, thanks for the faster RLock!

If your patch is commited, you can reconsider #3618 (possible deadlock
in python IO implementation).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3001>
_______________________________________