[gambit-list] Problem in thread-sleep! may be a poor

Marc Feeley feeley at iro.umontreal.ca
Wed Jan 28 00:22:23 EST 2009


On 27-Jan-09, at 10:33 PM, Oisín Mac Fhearaí wrote:

> 2009/1/28 Marc Feeley <feeley at iro.umontreal.ca>:
>> David St-Hilaire was experimenting with the following program:
>> .....
>> (pp n) ;; expected value of n is approximately 10000
>>
>> The value printed for n on his Linux computer is approximately  
>> 100.  When I
>> try the program on my Mac OS X computer I get a value much closer  
>> to the
>> expected 10000.
>>
>> After digging around it seems that the resolution of the "timeout"  
>> parameter
>> to the "select" system call (which is used by the scheduler to wait  
>> for I/O
>> and/or a timeout) can vary greatly from one OS to another.
>>
>> I'm curious to know how well other operating systems handle the  
>> timeout.
>> So, if you have access to some unusual operating system, could you  
>> try the
>> above program and report back what value is printed?
>
> Are you sure? I'm also on OS X (10.5 on a reasonably fast x86) and I
> get almost exactly 100 every time for the program you pasted:
>
> Lyrebird:sicp oisin$ gsi test-threads.scm
> 99
> Lyrebird:sicp oisin$ gsi test-threads.scm
> 99
> Lyrebird:sicp oisin$ gsi test-threads.scm
> 102
> Lyrebird:sicp oisin$ gsi test-threads.scm
> 101
> Lyrebird:sicp oisin$ gsi test-threads.scm
> 100
>
> It behaves the same when compiled. So even in the same OS (unless
> you're on a different version of OS X?), it seems these scheduler
> settings can drastically alter thread performance characteristics.

There was a recently repaired bug with thread-sleep! that can cause  
this behavior.  Please rerun the tests after updating with the latest  
patches (i.e. run "make update" first).

Marc




More information about the Gambit-list mailing list