[ python-Bugs-1234979 ] Lock.acquire treats only 1 as True

[SourceForge.net]

Bugs item #1234979, was opened at 2005-07-08 17:25
Message generated for change (Comment added) made by cperkins
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Chris Perkins (cperkins)
Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: Lock.acquire treats only 1 as True

Initial Comment:
Lock.acquire takes an argument indicating whether or
not to block.

On Windows, an argument of 1 (or True) is treated as
True, and any other number is treated as False.

The problem is in PyThread_acquire_lock, in thread_nt.h.

Although I haven't tried it on any other platform,
looking at a random sample (thread_pthread.h and
thread_solaris.h), it looks to me like other platforms
do it right.


----------------------------------------------------------------------

>Comment By: Chris Perkins (cperkins)
Date: 2005-07-09 10:43

Message:
Logged In: YES 
user_id=1142368

It looks like thread_wince.h suffers from the same problem.


----------------------------------------------------------------------

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-08 18:26

Message:
Logged In: YES 
user_id=1188172

Okay. Committed as Python/thread_nt.h r2.23.10.1, r2.24.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-07-08 18:10

Message:
Logged In: YES 
user_id=31435

birkenfeld, yes we should:  lock.acquire(waitflag) has been 
documented for more than a decade as treating any non-zero 
value as true, so this is a clear bug in thread_nt.h -- if 
someone was, e.g., relying on lock.acquire(2) acting like 
lock.acquire(0) on Windows, tough luck for them.  I'd even 
include this patch in a bugfix release, since the current 
meaning of lock.acquire(2) varies across platforms because 
of this bug, and that's a potentially serious problem.

----------------------------------------------------------------------

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-08 17:59

Message:
Logged In: YES 
user_id=1188172

Attaching a patch fixing that. Of course, the change is
slightly backwards-incompatible, so should we do that?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&group_id=5470