[issue3001] RLock's are SLOW
STINNER Victor
report at bugs.python.org
Sat Nov 7 09:57:23 CET 2009
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>
_______________________________________
More information about the Python-bugs-list
mailing list