Re: [MiNT] Issue with Mint 1.19 and Litchi (maybe solved)

[Vincent Rivière <vincent.riviere@freesbee.fr>]

On 06/02/2015 03:32, Pierre Ton-That wrote:
> Well, guess what? Fselect(1,...) is used by my internet programs, to
> wait for the second and next datas. So receiving functions are
> prematuraly exited.

Aha :-)

Regarding to this issue, I have 2 feelings.

1) Multitasking programs should not wait for extremely small delays such 
as 1ms. This suggests a very fast infinite loop in the main program, 
which would lead to things like 100% CPU usage when not necessary. 
Usually, this is a symptom of bad design, but of course there can be 
exceptions.

Normally, multitasking programs should:
- Either wait for a long delay for something to happen (a few seconds). 
So the kernel can give the CPU to other tasks.
- Either ask for a status and don't wait at all, carefully avoiding 
infinite loops which could result in 100% CPU.

2) In the Fselect() API, 0 means infinite delay. There was no way to ask 
it to return immediately with no delay. On the opposite, in the select() 
UNIX call, 0 means no delay, and that's what programs such as vim expect.

Alan introduced a new behaviour in Fselect() to fix the slowness of old 
binaries:
- 0: infinite delay (as usual)
- 1: NEW: no delay
- 2 and higher: normal delay

We assumed that it was safe, because no programs were supposed to 
deliberately call Fselect(1,...). But we were wrong, that change broke 
MyAES and Pierre's software.

Anyway:
In recent MiNTLib, the select() UNIX function has be implemented using 
Fpoll() instead Fselect(), so recently recompiled programs such as vim 
have no problem with the old Fselect() implementation. The Fpoll() API 
supports no-delay.

Finally, I think we should consider to revert the Fselect() change in 
FreeMiNT, since it broke old software, and it is no more useful for new 
binaries...

--
Vincent Rivière