Message157693
> I have a lock that may or may not be currently held when I release it,
> and now I know I can just catch RuntimeError in that case.
Only if you're willing to make assumptions about the threading model and the source of locks. And I fear the current change overpromises.
For example, the LockType from _dummy_thread raises an error not based on RuntimeError, and has comments suggesting it might stop raising entirely. I believe I have seen other Lock-emulation code which also does not raise an error, though the closest I can come to finding it right now is logging_releaseLock() when the import of either _thread or threading failed.
Starting with http://hg.python.org/cpython/file/acea9d95a6d8/Doc/library/threading.rst
I would prefer to change to following two sentences:
If an attempt is made to release an unlocked lock, a :exc:`RuntimeError` will be raised.
...
When invoked on an unlocked lock, a :exc:`ThreadError` is raised.
in any of the following ways:
(a) Change "will be"/"is" --> "may be", so it isn't promised:
If an attempt is made to release an unlocked lock, a :exc:`RuntimeError` may be raised.
...
When invoked on an unlocked lock, a :exc:`ThreadError` may be raised.
(b) Clarify that it is implementation-specific
If an attempt is made to release an unlocked _thread.lock, a :exc:`RuntimeError` will be raised.
...
When invoked on an unlocked _thread.lock, a :exc:`ThreadError` is raised.
(and add to the caveats)
Locks provided by other modules may have slightly different behavior, particularly when an an operation fails. For example, unlocking without first acquiring may raise a different error, or may not raise at all.
(c) Clarify that alternatives are buggy (and fix those in the stdlib)
If an attempt is made to release an unlocked lock, a :exc:`RuntimeError` will be raised.
...
When invoked on an unlocked lock, a :exc:`ThreadError` is be raised.
(and add to the caveats)
Historically, many Locks have followed a slightly different contract, particularly when an an operation fails. For example, unlocking without first acquiring might raise a different error, or might not even raise at all. |
|
Date |
User |
Action |
Args |
2012-04-06 21:37:34 | Jim.Jewett | set | recipients:
+ Jim.Jewett, georg.brandl, pitrou, r.david.murray, sandro.tosi, docs@python, python-dev |
2012-04-06 21:37:34 | Jim.Jewett | set | messageid: <1333748254.68.0.124351557565.issue14502@psf.upfronthosting.co.za> |
2012-04-06 21:37:34 | Jim.Jewett | link | issue14502 messages |
2012-04-06 21:37:33 | Jim.Jewett | create | |
|