Message71546
| Author |
pitrou |
| Recipients |
Rhamphoryncus, giampaolo.rodola, gregory.p.smith, jcea, pitrou, sserrano, vstinner |
| Date |
2008年08月20日.14:17:05 |
| SpamBayes Score |
4.2663764e-06 |
| Marked as misclassified |
No |
| Message-id |
<1219241828.87.0.0582704132386.issue3001@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Wow, that was quick. Did you try to replace threading.RLock with your
implementation, and run the tests?
By the way:
> - acquire() method argument "blocking" is not a keyword
> - In the Python version, RLock._release_save() replaces owner and
> counter attributes before release the lock. But releasing the lock may
> fails and no the object is in an inconsistent state
Removing the debugging statements is fine, but apart from that the C
implementation should mimick the current behaviour. Even if this
behaviour has potential pitfalls.
Speaking of which, it would be nice if RLock was subclassable. I don't
know whether any software relies on this though. |
|