[gccsdk] Unixlib select bug?

Lee Noar lee.noar at sky.com
Sat Mar 28 13:30:20 PDT 2020


On 27/03/2020 11:37, Chris Johns wrote:
> Not sure if this is the right place to post this..

Yes, this is the right place.

> I think there is a bug in the select() timeout logic - the effect is it 
> seems to ignore the tv_usec part of the timeout. Python's time.sleep 
> used select to do the actual waiting, and it was found that it just 
> ignored the fractional part, so sleep(0.2) would just return. In fact 
> sleep (0.99) also just returns, sleep (1.0) sleeps for a second, 
> sleep(1.99) also sleeps for a second..
> 
> I had a look at the logic in ul_select.c and it appears to use this to 
> work out then end time..
> 
>            end = now + timeout->tv_sec * 100
>              + (50000 + timeout->tv_usec) / 1000000;
> 
> However, the tv_usec part will just get end up as 0 (unless its > 
> 1000000, but that will get rejected by the earlier check). I think the 
> problem is it's converting usec to seconds, rather than usec to 
> centiseconds, so it should be:
> 
>            end = now + timeout->tv_sec * 100
>              + (500 + timeout->tv_usec) / 10000;
> 
> In fact:
> 
>            end = now + timeout->tv_sec * 100 + timeout->tv_usec / 10000;
> 
> Might be enough.

Ok, thanks, I'll try that. I've had trouble with select() myself for
some time. I've been suspecting for a while that it can get stuck in
an infinite loop. If calling Wimp_Poll from the same thread, then the
desktop comes to a halt. Your findings may well be the explanation.

Lee.



More information about the gcc mailing list