[RFC] libvncclient: use poll() if available

[tobydox]

select() does not work with file descriptors > 1024 so use the more modern poll() function if available. This also avoids the overhead of allocating/managing the quite huge fd_set structure.

This is a draft and any feedback, especially about the proper usage of poll() in all 3 different cases (waiting for socket connection, waiting for data to be read, waiting for data to be written), is welcome. Of course if there are no objections, the changes also can be merged.

[bk138]

Hi Toby, thanks for the PR!

Some general thoughts:

• PRO: poll() can use fds > 1024
  • in what situation would one ever run into this with a client?
• CON:
  • more code, more complexity :-)
  • it's not faster than select() AFAIK

Are there more pros and cons you can think of? How would you weigh them?

Some resources I know of:

• https://daniel.haxx.se/docs/poll-vs-select.html
• https://devarea.com/linux-io-multiplexing-select-vs-poll-vs-epoll/

Thanks!

[tobydox]

We have customers who actually do establish many VNC connections in parallel on the one hand and on the other hand due to other components in the program allocating file descriptors (pipes, socket notifiers etc.), 1024 file descriptors in total are exceeded quickly. So yes complexity is increased but may be we can also find a better way of structuring the code besides macros (e.g. a polling wrapper which either uses poll() or select()).

[bk138]

OK I see. Well my first plan was to use something like libev, libuv or libevent as a base, but I ended up thinking that implementing everything from scratch in Rust using tokio would be the very best approach ;-)

I'll do a in-depth review and then this can probably get merged as an incremental improvement.

[tobydox]

Patch rebased / ping