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 Jim.Jewett
Recipients Jim.Jewett, docs@python, georg.brandl, pitrou, python-dev, sandro.tosi
Date 2012-04-06.19:37:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CA+OGgf4-pmHB0GXMN9meZzMxB8z0Ye8EjFpPYegV14yEyEO9fQ@mail.gmail.com>
In-reply-to <1333705934.3395.0.camel@localhost.localdomain>
Content
On Fri, Apr 6, 2012 at 5:57 AM, Antoine Pitrou <report@bugs.python.org> wrote:
> Antoine Pitrou <pitrou@free.fr> added the comment:

>> > Not sure what you're talking about. The doc patch is about unacquired
>> > locks, not locks that someone else (another thread) holds.

>> Isn't one common reason for not being able to acquire a lock that
>> someone else was already holding it?

> We're talking about *releasing* an (un)acquired lock, not acquiring it
> again...

Right, but I thought the original motivation was concern over a race
condition in the lock acquisition.

    lock.acquire()
    try:                    # What if something happens here, during
try setup?  Leak?
        foo()
    finally:
        lock.release()

vs

    try:
        lock.acquire()
        foo()
    finally:
        lock.release()               # But what if the acquire failed?

-jJ
History
Date User Action Args
2012-04-06 19:37:14Jim.Jewettsetrecipients: + Jim.Jewett, georg.brandl, pitrou, sandro.tosi, docs@python, python-dev
2012-04-06 19:37:14Jim.Jewettlinkissue14502 messages
2012-04-06 19:37:14Jim.Jewettcreate