subject:"\[issue11618\] Locks broken wrt timeouts on Windows"


Kristján Valur Jónsson krist...@ccpgames.com added the comment:

Yes, the race condition with the timeout is a problem.
Here is a patch that implements this lock using a condition variable.
I agree that one must consider performance/simplicity when doing this.

--
Added file: http://bugs.python.org/file21322/locktimeout2.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Antoine Pitrou pit...@free.fr added the comment:

 Yes, the race condition with the timeout is a problem.
 Here is a patch that implements this lock using a condition variable.
 I agree that one must consider performance/simplicity when doing this.

I don't understand why you need something that complicated. A simple
semaphore should be enough (as in the POSIX implementation).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Kristján Valur Jónsson krist...@ccpgames.com added the comment:

I'm just providing this as a fast alternative to the Semaphore, which as far as 
I know, will cause a kernel call every time.

Complicated is relative.  In terms of the condition variable api, I wouldn't 
say that it is.  But given the fact that we have to emulate condition variables 
on older windows, then yes, it is complex.

If we are rolling our own instead of using Semaphores (as has been suggested 
for performance reasons) then using a Condition variable is IMHO safer than a 
custom solution because the correctness of that approach is so easily provable.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Antoine Pitrou pit...@free.fr added the comment:

 I'm just providing this as a fast alternative to the Semaphore, which
 as far as I know, will cause a kernel call every time.

A Semaphore might be slow, but I'm not sure other primitives are
faster. For the record, I tried another implementation using a critical
section, and it's not significantly faster under a VM (even though MSDN
claims critical sections are fast).

Have you timed your solution?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows

sbt shibt...@gmail.com added the comment:

If we are rolling our own instead of using Semaphores (as has been
suggested for performance reasons) then using a Condition variable is
IMHO safer than a custom solution because the correctness of that
approach is so easily provable.

Assuming that you trust the implementation of condition variables, then I
agree. Unfortunately implementing condition variables correctly on Windows is
notoriously difficult. The patch contains the lines

+ Generic emulations of the pthread_cond_* API using
+ Win32 functions can be found on the Web.
+ The following read can be edificating (or not):
+ http://www.cse.wustl.edu/~schmidt/win32-cv-1.html

Apparently all the examples from that web page are faulty one way or another.

http://newsgroups.derkeiler.com/Archive/Comp/comp.programming.threads/2008-07/msg00025.html

contains the following quote:

Perhaps this list should provide links to a reliable windows
condition variable implementation instead of continuously bad
mouthing the ~schmidt/win32-cv-1.html page and thereby raising
it's page rank. It would greatly help out all us newbies out here.

pthreads-w32 used to use a solution depending on that paper but changed to
something else. The following is a long but relevant read:

ftp://sourceware.org/pub/pthreads-win32/sources/pthreads-w32-2-8-0-release/README.CV

Of course implementing condition variables is a whole lot easier if you don't
need to broadcast and you only need weak guarantees on the behaviour. So
python's implementation may be quite sufficient. (It does appear that a thread
which calls COND_SIGNAL() may consume that signal with a later call of
COND_WAIT(). A proper implementation should never allow that because it can
cause deadlocks in code depending on normal pthread sematics.)

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Kristján Valur Jónsson krist...@ccpgames.com added the comment:

Emulating condition variables on windows became easy once Semaphores were 
provided by the OS because they provide a way around the lost wakeup problem.  
The current implementation in cpython was submitted by me :)  The source 
material is provided for reference only.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


sbt shibt...@gmail.com added the comment:

Benchmarks (on an old laptop running XP without a VM) doing

D:\Repos\cpython\PCbuildpython -m timeit -s from threading import Lock; l = 
Lock() l.acquire(); l.release()
100 loops, best of 3: 0.934 usec per loop

default:0.934
locktimeout.patch:  0.965
semlocknt.patch:2.76
locktimeout2.patch: 2.03

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Kristján Valur Jónsson krist...@ccpgames.com added the comment:

Btw, the locktimeout.patch appears to have a race condition.  
LeaveNonRecursiveMutex may SetEvent when there is no thread waiting (because a 
timeout just occurred, but the thread on which it happened is still somewhere 
around line #62 ).  This will cause the next WaitForSingleObject() to succeed, 
when it shouldn't.

It is this race between the timeout occurring, and the ability of us being able 
to register that in the lock's bookkeeping, that is the source of all the race 
problems with the timeout.  This is what prompted me to submit the condition 
variable version.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Antoine Pitrou pit...@free.fr added the comment:

Just for the record, here is the critical section-based version.

I would still favour committing the semaphore-based version first (especially 
in 3.2), and then discussing performance improvements if desired.

--
Added file: http://bugs.python.org/file21325/critlocknt.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


sbt shibt...@gmail.com added the comment:

 Btw, the locktimeout.patch appears to have a race condition.  
 LeaveNonRecursiveMutex may SetEvent when there is no thread waiting 
 (because a timeout just occurred, but the thread on which it happened 
 is still somewhere around line #62 ).  This will cause the next 
 WaitForSingleObject() to succeed, when it shouldn't.

I believe the lock is still in a consistent state.  If this race happens and 
SetEvent() is called then we will must have mutex-owned  -1 because the timed 
out waiter is still counted by mutex-owned.  This prevents the tests involving 
interlocked functions from giving true.  Thus WaitForSingleObject() is the ONLY 
way for a waiter to get the lock.

In other words, as soon as a timeout happens the fast interlocked path gets 
blocked.  It is only unblocked again after a call to WaitForSingleObject() 
succeeds: then the thread which now owns the lock fixes mutex-owned using 
mutex-timeouts and the interlocked path is operational again (unless another 
timeout happens).

I can certainly understand the desire to follow the KISS principle.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Kristján Valur Jónsson krist...@ccpgames.com added the comment:

Antoine:  I agree, the semaphore is the quick and robust solution.

sbt: I see your point.  Still, I think we still may have a flaw:  The statement 
that (owned-timeouts) is never an under-estimate isn't true on modern 
architectures, I think.  The order of the atomic decrement operations in the 
code means nothing and cannot be depended on to guarantee such a claim:  The 
thread doing the reading may see the individual updates in any order, and so 
the estimate may be an over- or an underestimate.

It would fix this and simplify things a lot to take the special case for 
timeout==0 out of the code.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


sbt shibt...@gmail.com added the comment:

sbt wrote:
-
I see your point.  Still, I think we still may have a flaw:  The statement that 
(owned-timeouts) is never an under-estimate isn't true on modern architectures, 
I think.  The order of the atomic decrement operations in the code means 
nothing and cannot be depended on to guarantee such a claim:  The thread doing 
the reading may see the individual updates in any order, and so the estimate 
may be an over- or an underestimate.
-

The interlocked functions act as read (and write) memory barriers, so 
mutex-timeout is never any staler than the value of owned obtained from the 
preceeding interlocked function call.  As you say my claim that (owned-timeout) 
is never an underestimate is dubious.  But the only time I use this quantity is 
in this bit:

else if (owned - mutex-timeouts != -1) /* harmless race */
return WAIT_TIMEOUT ;

If this test gives a false negative we just fall through to the slow path (no 
problem).  If we get a false positive it is because one of the two following 
races happened:

1) Another thread just got the lock: letting the non-blocking acquire fail is 
clearly the right thing to do.

2) Another thread just timed out: this means that a third thread must have held 
the lock up until very recently, so allowing a non-blocking acquire to fail is 
entirely reasonable (even if WaitForSingleObject() might now succeed).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Kristján Valur Jónsson krist...@ccpgames.com added the comment:

There is no barrier in use on the read part.  I realize that this is a subtle 
point, but in fact, the atomic functions make no memory barrier guarantees 
either (I think).  And even if they did, you are not using a memory barrier 
when you read the 'timeouts' to perform the subtraction.  On a multiprocessor 
machine the two values can easily fall on two cache lines and become visible to 
the other cpu in a random fashion.  In other words:  One cpu decreases the 
owner and timeouts at about the same time.  A different thread, on a 
different cpu may see the decrease in owner but not the decrease in 
timeouts until at some random later point.

Lockless algorithms are notoriously hard and it is precisely because of subtle 
pitfalls like these.  I could even be wrong about the above, but that would not 
be blindingly obvious either.  I'm sure you've read something similar but this 
is where I remember seeing some of this stuff mentioned:  
http://msdn.microsoft.com/en-us/library/ee418650(v=vs.85).aspx

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Kristján Valur Jónsson krist...@ccpgames.com added the comment:

Antoine:  I notice that even the fast path contains a ResetEvent() call.  I 
think this is a kernel call and so just as expensive as directly using a 
semaphore :).  Otherwise, the logic looks robust, although ResetEvent() and 
Event objects always give me an uneasy feeling.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Antoine Pitrou pit...@free.fr added the comment:

 Antoine:  I notice that even the fast path contains a ResetEvent()
 call.  I think this is a kernel call and so just as expensive as
 directly using a semaphore :)

Yes, in my timings it doesn't show significant improvements compared to
the semaphore approach (although again it's on a VM, so I'm not sure how
much this reflects a native Windows system).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


sbt shibt...@gmail.com added the comment:

krisvale wrote

There is no barrier in use on the read part.  I realize that this is a subtle 
point, but in fact, the atomic functions make no memory barrier guarantees 
either (I think).  And even if they did, you are not using a memory barrier 
when you read the 'timeouts' to perform the subtraction.  On a multiprocessor 
machine the two values can easily fall on two cache lines and become visible to 
the other cpu in a random fashion.  In other words:  One cpu decreases the 
owner and timeouts at about the same time.  A different thread, on a 
different cpu may see the decrease in owner but not the decrease in 
timeouts until at some random later point.


From the webpage you linked to:

Sometimes the read or write that acquires or releases a resource is done using 
one of the InterlockedXxx functions. On Windows this simplifies things, because 
on Windows, the InterlockedXxx functions are all full-memory barriers—they 
effectively have a CPU memory barrier both before and after them, which means 
that they are a full read-acquire or write-release barrier all by themselves.


Interlocked functions would be pretty useless for implementing mutexes if they 
did not also act as some kind of barrier: preventing two threads from 
manipulating an object at the same time is not much use if they don't also get 
up-to-date views of that object while they own the lock.

Given that mutex-timeout is only modified by interlocked functions, an 
unprotected read of mutex-timeout will get a value which is at least as fresh 
as the one available the last time we crossed a barrier by calling 
InterlockedXXX() or WaitForSingleObject().

Note that if the read of mutex-timeouts in this line

if ((timeouts = mutex-timeouts) != 0)

gives the wrong answer it will be an underestimate because we own the lock 
and the only other threads which might interfere will be incrementing the 
counter.  The worst that can happen is that the fast path remains blocked: 
consistency is not affected.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows

2011-03-21 Thread Martin v . Löwis


Martin v. Löwis mar...@v.loewis.de added the comment:

 I would still favour committing the semaphore-based version first
 (especially in 3.2), and then discussing performance improvements if
 desired.

For 3.2, I would prefer a solution that makes least changes to the
current code. This is better than fundamentally replacing the
synchronization mechanism which locks are based on.

For 3.3, I predict that any Semaphore-based version will be shortly
replaced by something fast. Benchmarks seem to indicate that you can
get much faster than semaphores.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows

2011-03-21 Thread Martin v . Löwis


Martin v. Löwis mar...@v.loewis.de added the comment:

 I realize that this is
 a subtle point, but in fact, the atomic functions make no memory
 barrier guarantees either (I think).

No need to guess:

http://msdn.microsoft.com/en-us/library/ms683560(v=vs.85).aspx

This function generates a full memory barrier (or fence) to ensure that
memory operations are completed in order.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows

2011-03-20 Thread sbt


New submission from sbt shibt...@gmail.com:

In thread_nt.h, when the WaitForSingleObject() call in
EnterNonRecursiveMutex() fails with WAIT_TIMEOUT (or WAIT_FAILED) the
mutex is left in an inconsistent state.

Note that the first line of EnterNonRecursiveMutex() is the comment

/* Assume that the thread waits successfully */

Allowing EnterNonRecursiveMutex() to fail with a timeout obviously
violates this promise ;-)  I think the problem was introduced to Python
3.2 with:

 Issue7316: Add a timeout functionality to common locking operations.


The following Windows session demonstrates unexpected behaviour:

Python 3.3a0 (default, Mar 19 2011, 18:16:48) [MSC v.1500 32 bit (Intel)] on 
win32
Type help, copyright, credits or license for more information.
 import threading
 l = threading.Lock()
 l.acquire()
True
 l.acquire(timeout=1)
False
 l.release()
 l.locked()  # should return False
True
 l.acquire(blocking=False)   # should return True
False


Also, after a timeout, uncontended acquires/releases always take the
slow path:

D:\Repos\cpython\PCbuildpython -m timeit ^
More? -s from threading import Lock; l = Lock() ^
More? l.acquire();l.release()
100 loops, best of 3: 0.974 usec per loop

D:\Repos\cpython\PCbuildpython -m timeit ^
More? -s from threading import Lock; l = Lock() ^
More? -s l.acquire();l.acquire(timeout=0.1);l.release() ^
More? l.acquire();l.release()
10 loops, best of 3: 2.18 usec per loop


A unit test is attached which passes on Linux but has three failures
on Windows.


The owned field of NRMUTEX is a count of the number of threads
waiting for the mutex (not including the owner).  owned will
over-estimate the number of waiters if a timeout occurs, because the
timed out thread will still be counted as a waiter.

The obvious fix is to decrement mutex-owned when a timeout occurs.
Unfortunately that would introduce a race which might allow two
threads to think they own the lock at the same time.

I also notice that EnterNonRecursiveMutex() wrongly sets
mutex-thread_id to the current thread even when it fails with a
timeout.  It appears that the thread_id field is never actually used
-- is it there to help with debugging?  Perhaps it should just be
removed.

BTW only thread_pthread.h and thread_nt.h have implementations of
PyThread_acquire_lock_timed().  Since this function appears to be
required by _threadmodule.c, does this mean that in Python 3.2
threads are only supported with pthreads and win32?  If so you can
get rid of all those other thread_*.h files.

--
files: test-timeout.py
messages: 131515
nosy: sbt
priority: normal
severity: normal
status: open
title: Locks broken wrt timeouts on Windows
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21304/test-timeout.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Changes by Antoine Pitrou pit...@free.fr:


--
nosy: +krisvale, pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Antoine Pitrou pit...@free.fr added the comment:

 It appears that the thread_id field is never actually used
 -- is it there to help with debugging?  Perhaps it should just be
 removed.

True, I think we can remove it.

 does this mean that in Python 3.2
 threads are only supported with pthreads and win32?  If so you can
 get rid of all those other thread_*.h files.

Getting ridding them is scheduled for 3.3.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows

2011-03-20 Thread sbt


sbt shibt...@gmail.com added the comment:

First stab at a fix.

Gets rid of mutex-thread_id and adds a mutex-timeouts counter.

Does not try to prevent mutex-owned from overflowing.

When no timeouts have occurred I don't think it changes behaviour, and it uses 
the same number of Interlocked functions.

--
keywords: +patch
Added file: http://bugs.python.org/file21306/locktimeout.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Antoine Pitrou pit...@free.fr added the comment:

Well, Windows 2000 has semaphores, so why not use them? It makes the code much 
simpler. Patch attached (including test).

--
nosy: +loewis
Added file: http://bugs.python.org/file21308/semlocknt.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Changes by Antoine Pitrou pit...@free.fr:


--
nosy: +brian.curtin, tim.golden

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows

2011-03-20 Thread sbt


sbt shibt...@gmail.com added the comment:

Have you tried benchmarking it?

Interlocked functions are *much* faster than Win32 mutex/semaphores in the 
uncontended case.  

It only doubles the time taken for a l.acquire(); l.release() loop in Python 
code, but at the C level it is probably 10 times slower.  

Do you really want the GIL to be 10 times slower in the uncontended case? ;-)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Antoine Pitrou pit...@free.fr added the comment:

 Have you tried benchmarking it?
 
 Interlocked functions are *much* faster than Win32 mutex/semaphores in
 the uncontended case.  

Well, I'd rather have obviously correct code than
difficult-to-understand speedy code.

The patch I've posted takes less than a microsecond per acquire/release
pair, and that's in a virtual machine to begin with.

 Do you really want the GIL to be 10 times slower in the uncontended case? ;-)

The GIL doesn't use these functions (see ceval_gil.h).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows

2011-03-20 Thread Martin v . Löwis


Martin v. Löwis mar...@v.loewis.de added the comment:

Interestingly, it used to be a Semaphore up to [5e6e9e893acd]; in 
[cde4da18c4fa], Yakov Markovitch rewrote this to be the faster implementation 
we have today.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows


Antoine Pitrou pit...@free.fr added the comment:

 Interestingly, it used to be a Semaphore up to [5e6e9e893acd]; in
 [cde4da18c4fa], Yakov Markovitch rewrote this to be the faster
 implementation we have today.

At that time, the Pythread_* functions were still in use by the GIL
implementation, and it made a difference judging by the commit message.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows

2011-03-20 Thread Martin v . Löwis


Martin v. Löwis mar...@v.loewis.de added the comment:

 At that time, the Pythread_* functions were still in use by the GIL
 implementation, and it made a difference judging by the commit message.

Hmm. And if some application uses thread.lock heavily, won't it still
make a difference?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11618
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11618] Locks broken wrt timeouts on Windows