This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: hyperthreading fix try #2

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/ -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:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]