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 kristjan.jonsson
Recipients Sebastian.Noack, asvetlov, christian.heimes, jyasskin, kristjan.jonsson, mklauber, neologix, pitrou, sbt
Date 2012-10-02.09:58:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1349171898.15.0.953959406688.issue8800@psf.upfronthosting.co.za>
In-reply-to
Content
> We've already departed from that. Our Lock is nothing like a mutex, for
> example (it's more of a binary semaphore).

This is not by nature of good design, but an accident.  C python needed both mutex and signaling ability and decided that a single non-recursive lock were good enough for that.  This is a debatable choice since all modern systems consider these two different needs and provide different primitives to satisfy them.  The "Lock" was then exposed to Python and RLock grafted on top to fix the non-recursiveness problem.  Then we added signaling in the form of Events, Semaphores and Condition variables.
Had this ben more purposefully designed, then there would be no Lock or RLock in threading.py, only a Mutex.
History
Date User Action Args
2012-10-02 09:58:18kristjan.jonssonsetrecipients: + kristjan.jonsson, pitrou, christian.heimes, jyasskin, asvetlov, neologix, sbt, mklauber, Sebastian.Noack
2012-10-02 09:58:18kristjan.jonssonsetmessageid: <1349171898.15.0.953959406688.issue8800@psf.upfronthosting.co.za>
2012-10-02 09:58:18kristjan.jonssonlinkissue8800 messages
2012-10-02 09:58:17kristjan.jonssoncreate