This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jyasskin
Recipients jyasskin, kristjan.jonsson, pitrou
Date 2010-05-24.20:44:35
SpamBayes Score 0.0070145177
Marked as misclassified No
Message-id <1274733877.04.0.796457163078.issue8800@psf.upfronthosting.co.za>
In-reply-to
Content
You're definitely right that posix and java don't make these usable from the normal lock API. And I don't think it's essential that they be usable as RLocks, although it's nice for Conditions. I think what I'm actually saying is that, if you have an acquire() operation on RWLock, then it has to forward to the write lock. Forwarding to the read lock would have different semantics from RLock.acquire (2 threads could get in at once) and so would be incorrect.

I agree that RWLock is more obvious. As long as the docs mention that it's equivalent to a shared/exclusive lock, I don't care that much about the name. Just throwing out ideas.
History
Date User Action Args
2010-05-24 20:44:37jyasskinsetrecipients: + jyasskin, pitrou, kristjan.jonsson
2010-05-24 20:44:37jyasskinsetmessageid: <1274733877.04.0.796457163078.issue8800@psf.upfronthosting.co.za>
2010-05-24 20:44:35jyasskinlinkissue8800 messages
2010-05-24 20:44:35jyasskincreate