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

["Helmut Karlowski" <helmut.karlowski@ish.de>]

Am 07.02.2015, 11:15 Uhr, schrieb markus@mubf.de:

> 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 think yes.

> 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?

That's libc-standard:

http://www.gnu.org/software/libc/manual/html_node/Waiting-for-I_002fO.html#Waiting-for-I_002fO
-----------------------
Data Type: fd_set

The fd_set data type represents file descriptor sets for the select  
function. It is actually a bit array.
Macro: int FD_SETSIZE

The value of this macro is the maximum number of file descriptors that a  
fd_set object can hold information about. On systems with a fixed maximum  
number, FD_SETSIZE is at least that number. On some systems, including  
GNU, there is no absolute limit on the number of descriptors open, but  
this macro still has a constant value which controls the number of bits in  
an fd_set; if you get a file descriptor with a value as high as  
FD_SETSIZE, you cannot put that descriptor into an fd_set.

...

int select (int nfds, fd_set *read-fds, fd_set *write-fds, fd_set  
*except-fds, struct timeval *timeout)
-------------------------

So the maximum handle to listen to is limited to the number of bits in the  
argument to select (64 on cygwin).

Unless you redefine that all, but I don't know if it would break some  
standard software.

> What do you think?

I think it's all a hack ;)

-Helmut

--