| 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) *  |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2008-01-19 13:57 |
| The problem was fixed and the OP suggested to close the bug. |
|
|