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.

classification
Title: dummy_thread LockType.acquire() always returns None, should be True or False
Type: behavior Stage:
Components: Library (Lib) Versions: Python 2.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: brett.cannon Nosy List: brett.cannon, mishok13, toymachine
Priority: normal Keywords: patch

Created on 2008-07-11 07:52 by toymachine, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
issue3339.diff mishok13, 2008-07-11 08:12
Messages (3)
msg69539 - (view) Author: Henk Punt (toymachine) Date: 2008-07-11 07:52
Class LockType always seems to be returning None if waitflag is not
specified.

If you look up the documentation for the non dummy lock in lib ref
15.3.1 , none of the possible
results should be ‘None’, in fact it would always return True, except
when non-block is specified
And another thread is already holding the lock then it would return False

From the docs on acquire():

Acquire a lock, blocking or non-blocking. 
When invoked without arguments, block until the lock is unlocked, then
set it to locked, and return true. 
When invoked with the blocking argument set to true, do the same thing
as when called without arguments, and return true. 
When invoked with the blocking argument set to false, do not block. If a
call without an argument would block, return false immediately;
otherwise, do the same thing as when called without arguments, and
return true.
msg69540 - (view) Author: Andrii V. Mishkovskyi (mishok13) Date: 2008-07-11 08:12
Seems like inconsistency to me, this simple patch should fix it.
msg69605 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-07-13 01:21
r64903-64905 have the fixes for trunk, 3.0, and 2.5, respectively.
Thanks for reporting this, Henk. Andrii, I never even looked at your
patch since while I was evaluating the bug the problem was rather
obvious and simple, as you said. =) Thanks for the work, though.
History
Date User Action Args
2022-04-11 14:56:36adminsetgithub: 47589
2008-07-13 01:22:01brett.cannonsetresolution: accepted -> fixed
2008-07-13 01:21:45brett.cannonsetstatus: open -> closed
resolution: accepted
messages: + msg69605
2008-07-11 16:32:08brett.cannonsetassignee: brett.cannon
nosy: + brett.cannon
2008-07-11 08:12:03mishok13setfiles: + issue3339.diff
keywords: + patch
messages: + msg69540
nosy: + mishok13
2008-07-11 07:52:34toymachinecreate