Irit Katriel added the comment:
The differences were documented under issue23484:
https://github.com/python/cpython/commit/407c497e83b86011173fbf25e9a08b81adad5477
--
nosy: +iritkatriel
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder: ->
Davin Potts added the comment:
Since the time of its introduction in 2.6, a call to
multiprocessing.Lock.release on an already unlocked lock resulted in behavior
that did not match that of threading.Lock.release (which raised a thread.error
as far back as 2.4 and probably longer than that
Changes by Davin Potts pyt...@discontinuity.net:
--
versions: +Python 2.7, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21342
___
___
Davin Potts added the comment:
The discussion in issue23484 is leading to a recommendation that the docs be
changed to reflect the actual behavior of multiprocessing's Lock and its close
relatives.
As far back as 2.6.9, calling release() on an unlocked threading.Lock triggered
a thread.error
R. David Murray added the comment:
As a historical note, the docs are probably correct...but at some point
relatively recently we fixed the inconsistency in what was raised in the thread
and threading modules, but obviously no one noticed that multiprocessing had
the same issue. It could be
Charles-François Natali added the comment:
Thanks for the patch.
That's IMO a good change, but I would only apply it to default, and not
backport it.
--
nosy: +neologix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21342
New submission from Steinn Steinsen:
In the documentation of multiprocessing the locks, RLock and Lock,
are said to be clones of their respective threading synchronization primitives.
There is an inconsistency in what exceptions are raised when an
unlocked lock is released. According to the
Changes by Ned Deily n...@acm.org:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21342
___
___
Python-bugs-list mailing list
