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=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.