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

["markus@mubf.de" <markus@mubf.de>]

Hello everybody,

took that as an occasion for contemplating a bit about the whole 
Fselect() issue.

With MiNT's new "virtually unlimited" number of handles, wouldn't it 
only consequent to consider Fselect() in its current implementation 
broken by design?

I mean, with MiNT able to hold (approximately) 240 open handles (that's 
at least what my tests on Aranym showed) and Fselect() only able to 
listen on 26 of them, isn't that asking for trouble anyway?

I'd like to propose to revert recent Fselect() changes (to avoid 
breaking "old" software) and introduce a new Fselect2() that better 
handles MiNT's new capabilities. This should at least allow to pass the 
(arbitrary) number of handles to listen on:

int Fselect2(int nfds, long *readfds, long *writefds, long *exceptfds, 
?? *timeout);

Instead of passing long bitmaps by value, it would pass pointers to long 
arrays with nfds indicating the length of these. Whether timeout would 
be some kind of struct pointer or not is debatable (at least it would 
allow mintlib's select() implementation to become more UNIXish). A 
struct pointer would make the semantics of "wait forever" (pointer is 
NULL) and "immediately return" (values are 0) clear.

Fselect() would than work as before, Fselect2() could be used by (new) 
mintlib to better support select().

My own knowledge of MiNT internals are (embarassingly) minimal but I 
could at least offer to try and put a prototype implementation together 
if anybody is willing to help.

What do you think?

Cheers,
Markus


Am 06.02.2015 um 13:31 schrieb Vincent Rivière:
> So I really wonder if keeping the new Fselect(1,...) behaviour is a 
> good thing...

P.S.: this is a resend from a message sent this morning that apparently 
didn't make it to the list. Apologize in advance if it appears twice now 
for some reason.