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]
http://bugs.python.org/issue1332
__
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
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]
http://bugs.python.org/issue1332
__
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
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
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 because
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
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
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;
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
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]
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!
12 matches
Mail list logo
