User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
On 08/02/15 10:17, Peter Persson wrote:
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?
I agree 100% with Markus in this case. It's not a good idea
to change existing system calls in a way that affect any
unknown number of existing programs, and compatibility for
these APIs are handled through mintlib. I'd much rather see
a nice implementation of Fselect2() :)
While on the subject, it would be nice to have a
solution for scenarios which requires very short timeouts.
Terminal emulators for example has to call both
Evnt_multi() and Fselect() to handle GEM and file I/O
respectively. It would be nice if we could fuse these
separate entities some way. I guess there are other
solutions to explore as well, running it as two separate
processes and passing data through the AES or something,
but I guess that would impact performance too.
I'm fine with reverting the change to Fselect(), but there's no need
for Fselect2() because the MiNTlib's version of select() now calls
Fpoll() anyway.