[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

Christian Heimes added the comment: The problem was fixed and the OP suggested to close the bug. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ _

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

Christian Heimes added the comment: 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

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

Warren DeLano added the comment: 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 **hi

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

Guido van Rossum added the comment: > 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; unfo

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

Warren DeLano added the comment: 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 ti

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

Christian Heimes added the comment: 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 P

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

Warren DeLano added the comment: 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. Added file: http://bugs.python.org/file8621/thread_nt_fix.patch

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

Guido van Rossum added the comment: > 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 becau

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

Warren DeLano added the comment: 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 GetPr

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

Warren DeLano added the comment: 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 W

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

Warren DeLano added the comment: Yes. Here's what I think the problem is: InterlockedCompareExchange called from EnterNonRecursiveMutex in thread_nt.h:101 seems to returns (-1) as 0x instead of 0x. Still working out why though...

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

Guido van Rossum added the comment: Can you step through it with a C/C++ debugger to see where it goes wrong? -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

New submission from Warren DeLano: 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! _

[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi

Changes by Warren DeLano: -- components: Windows nosy: delwarl severity: normal status: open title: threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]>