Message95014
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). |
|
Date |
User |
Action |
Args |
2009-11-07 08:57:23 | vstinner | set | recipients:
+ vstinner, gregory.p.smith, jcea, Rhamphoryncus, pitrou, hgibson50, giampaolo.rodola, kevinwatters, sserrano |
2009-11-07 08:57:23 | vstinner | set | messageid: <1257584243.44.0.810494399338.issue3001@psf.upfronthosting.co.za> |
2009-11-07 08:57:22 | vstinner | link | issue3001 messages |
2009-11-07 08:57:21 | vstinner | create | |
|