Message157678
| 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 |
|