hyperthreading fix try #2

Christopher Faylor cgf-no-personal-reply-please@cygwin.com
Mon Feb 14 10:16:00 GMT 2005

On Mon, Feb 14, 2005 at 01:17:03AM +1000, Nick Coghlan wrote:
>Nick Coghlan wrote:
>>Christopher Faylor wrote:
>>Of course, I don't actually know if this is a related problem or not. 
>>I'm hoping Chris can check it easily, since it happens with the standard 
>>Cygwin Python, not just with the version I built from Python's current CVS.
>I took the obvious step of running that test script directly, playing with 
>the number of threads spawned, and the number of files created by each 
>thread, as well as adding some more print statements to the script to see 
>where it was hanging.
>Command lines looked like (with thread and file counts filled in):
>$ python /lib/python2.4/test/test_threadedtempfile.py -t <threads> -f 
>The results weren't particularly deterministic, beyond a general 'more 
>threads, more files' -> 'more likely to hang'. 10 & 10 seemed to do it 
>fairly effectively although even that would occasionally succeed (the 
>default is 20 & 20).
>When it *did* hang, it was with a number of threads successfully opening 
>their files on an iteration, with the remainder of the threads locking up 
>attempting to open a new temporary file. The next time around, the 
>remaining threads would hang while attempting to open the temporary file.
>The main script hangs because it is waiting for the threads to terminate.

Is this a regression?  Was this also problem with 1.5.12?

Unless there are pipes involved in this test, I don't see how it could be
related to the problem.


Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

More information about the Cygwin mailing list