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.

Logged In: YES 
user_id=1188172

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

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.

Logged In: YES 
user_id=1188172

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

Logged In: YES 
user_id=1142368

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

Logged In: YES 
user_id=1188172

I see. Fixed as Python/thread_wince.h r2.8, r2.7.30.1.