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: threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Type: behavior Stage:
Components: Windows Versions: Python 2.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: christian.heimes, delwarl, gvanrossum, nnorwitz
Priority: normal Keywords:

Created on 2007-10-26 02:48 by delwarl, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
thread_nt_fix.patch delwarl, 2007-10-26 20:15
Messages (13)
msg56772 - (view) Author: Warren DeLano (delwarl) Date: 2007-10-26 02:54
import threading

rlock = threading.RLock()

rlock.acquire(0)

# always returns False with python-2.5.1.amd64.msi
# even though

rlock.acquire()

# returns True as expected.

# All attempts to acquire locks without blocking are foiled!
msg56803 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-10-26 17:52
Can you step through it with a C/C++ debugger to see where it goes wrong?
msg56808 - (view) Author: Warren DeLano (delwarl) Date: 2007-10-26 18:38
Yes.  Here's what I think the problem is:  InterlockedCompareExchange 
called from EnterNonRecursiveMutex in thread_nt.h:101 seems to returns 
(-1) as 0x00000000FFFFFFFF instead of 0xFFFFFFFFFFFFFFFF.  Still working 
out why though...
msg56811 - (view) Author: Warren DeLano (delwarl) Date: 2007-10-26 19:12
Hmm.  Well, for one thing, we're falling back on Python's 
interlocked_cmp_xchg instead of using Windows' 
InterlockedCompareExchange (or should it InterlockCompareExchange64?).  
Python's implementation is clearly assuming 64 bit counters, but the 
other native Windows Interlocked* functions may indeed be operating on 
32 bit counters, hence the mismatch.
msg56815 - (view) Author: Warren DeLano (delwarl) Date: 2007-10-26 19:36
Disabling Python's emulated InterlockedCompareExchange (for Win95 
compatibility) cures the problem, so the underlying question is why the 
existence of InterlockedCompareExchange is not being autodetected on 64 
bit systems -- and that is apparently because GetProcAddress
(kernel,"InterlockedCompareExchange") returns NULL -- which makes sense 
since InterlockedCompareExchange appears to be implemented using macros 
instead of being served up through kernel32.dll.

So is Win95 still a supported platform?  

If not, then perhaps InterlockedCompareExchange emulation can simply be 
deleted.  

If so, then either some other approach needs to be adopted to activate 
emulation, or the emulated code needs to be fixed to behave like the 
native windows functions (which appear to only operate on the lowest 32 
bits).
msg56816 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-10-26 19:39
> Disabling Python's emulated InterlockedCompareExchange (for Win95
> compatibility) cures the problem, so the underlying question is why the
> existence of InterlockedCompareExchange is not being autodetected on 64
> bit systems -- and that is apparently because GetProcAddress
> (kernel,"InterlockedCompareExchange") returns NULL -- which makes sense
> since InterlockedCompareExchange appears to be implemented using macros
> instead of being served up through kernel32.dll.
>
> So is Win95 still a supported platform?

Heavens no!

> If not, then perhaps InterlockedCompareExchange emulation can simply be
> deleted.

Patch please?
msg56819 - (view) Author: Warren DeLano (delwarl) Date: 2007-10-26 20:15
Patch attached.  Do note that this patch will break threading on Win95 
in order to achieve 64-bit compatibility.  Win98 and up should be 
fine -- however, that assertion has not yet been confirmed.
msg56822 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-10-26 20:50
The patch doesn't apply (r58677 of release25-maint). Can you please
create an unified diff against the latest subversion checkout with svn
diff or TortoiseSVN?

$ patch -p1 < thread_nt_fix.patch
missing header for context diff at line 3 of patch
patching file Python/thread_nt.h
Hunk #2 FAILED at 14.
Hunk #3 FAILED at 40.
2 out of 3 hunks FAILED -- saving rejects to file Python/thread_nt.h.rej
msg56836 - (view) Author: Warren DeLano (delwarl) Date: 2007-10-27 00:13
No need -- turns out the problem was fixed on April 21st a mere three 
days after Python 2.5.1 was released.  Please close this issue -- my 
rookie mistake not working with SVN source from the start! (gee, I 
should have known better...)  Sorry for wasting your time and mine.

However, considering the severity of this problem 
(threading.Lock.acquire(0) broken on 64-bit Windows), what do you think 
about issuing a 2.5.2 maintenance release?
msg56837 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-10-27 00:22
> However, considering the severity of this problem
> (threading.Lock.acquire(0) broken on 64-bit Windows), what do you think
> about issuing a 2.5.2 maintenance release?

Neal Norwitz and Anthony Baxter have been planning to release 2.5.2
for a while now; unfortunately both seem too busy to make much
progress. Any volunteers?
msg56839 - (view) Author: Warren DeLano (delwarl) Date: 2007-10-27 00:50
I wouldn't know how take the lead, but with customers breathing down 
my neck for x64 support, my own threading.Rlock-dependent software 
product cannot support x64 until an official Python release supports 
it.  

So I guess that automatically puts me in the **highly-
motivated/willing-to-help** camp, if there's anything useful I can 
actually do towards 2.5.2.
msg56860 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-10-27 19:45
Warren DeLano wrote:
> So I guess that automatically puts me in the **highly-
> motivated/willing-to-help** camp, if there's anything useful I can 
> actually do towards 2.5.2.

You can check every bugs related to 2.5 with urgent, high or no priority
and see if the bugs needs to be fixed for 2.5.2.

http://bugs.python.org/issue?@columns=title,id,activity,status&@sort=activity&@group=priority&@filter=versions,status&@pagesize=50&@startwith=0&status=1&versions=2

I guess at least the urgent and high priority bugs have to be addressed
for the new release.

Christian
msg60160 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-19 13:57
The problem was fixed and the OP suggested to close the bug.
History
Date User Action Args
2022-04-11 14:56:27adminsetgithub: 45673
2008-01-19 13:57:27christian.heimessetstatus: open -> closed
resolution: fixed
messages: + msg60160
2007-10-27 19:45:56christian.heimessetmessages: + msg56860
2007-10-27 00:50:51delwarlsetmessages: + msg56839
2007-10-27 00:22:55gvanrossumsetmessages: + msg56837
2007-10-27 00:13:12delwarlsetmessages: + msg56836
2007-10-26 20:50:10christian.heimessetnosy: + christian.heimes, nnorwitz
messages: + msg56822
2007-10-26 20:15:20delwarlsetfiles: + thread_nt_fix.patch
messages: + msg56819
2007-10-26 19:39:38gvanrossumsetmessages: + msg56816
2007-10-26 19:36:54delwarlsetmessages: + msg56815
2007-10-26 19:12:06delwarlsetmessages: + msg56811
2007-10-26 18:38:36delwarlsetmessages: + msg56808
2007-10-26 17:52:35gvanrossumsetnosy: + gvanrossum
messages: + msg56803
2007-10-26 02:54:02delwarlsetmessages: + msg56772
2007-10-26 02:48:31delwarlcreate