Re: [gccsdk] Unixlib select bug?

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.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK