6 ms·
> No new code should be using select(). Using it assumes the execution environment keeps all file descriptor values within FD_SETSIZE. Perhaps it might be time
by cesarb 5y ago
> No new code should be using select(). Using it assumes the execution environment keeps all file descriptor values within FD_SETSIZE.
Perhaps it might be time to start treating select() like gets() was treated: the compiler should emit a warning by default whenever it's used, and after perhaps a decade, the API should no longer be available for newly compiled code. While not as bad as gets(), which according to Rusty's classification of API quality (https://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html https://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html and https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html) gets a -10 ("It's impossible to get right"), select() is around a -5 ("Do it right and it will sometimes break at runtime"), or perhaps even a -7 ("The obvious use is wrong").
- pengaru 5y agoI agree 100% re: compiler throwing a warning like gets() for select().
- deleted 5y ago[deleted]
- viraptor 5y agoThis makes me wonder if we could realistically start enforcing SystemCallFilter on new services which immediately crashes an app of it tries to use select(). I suspect there's a lot of them that would fail at the moment... But maybe in a few years.
- kevin_thibedeau 5y agoselect() is useful on platforms without any poll variants.
- bonzini 5y agoOf which the only one left is Windows, where you probably have a completely different event loop anyway. The Windows select by the way does not have the limitations on the file descriptor that the article talks about, because Windows file descriptors are not small consecutive integers.
- beagle3 5y ago…… and at least until 2011 which was when I last checked, select() was the reliable way to do usleep() in Windows without having to change system time granularity, set up invisible windows with their own message pump or a variety of other weird and unreliable ways.
- kevin_thibedeau 5y agoThere are plenty of embedded platforms in the same boat.
- deleted 5y ago[deleted]
- geertj 5y agoActually that’s not totally accurate. The native IO model in the Win32 subsystem, I/O completion ports, is indeed completion based. But the NT kernel does have a scalable readiness model too, limited to sockets, that people have used to build an epoll(). See: https://github.com/piscisaureus/wepoll https://github.com/piscisaureus/wepoll. This is used by e.g. deno and node.
- the_mitsuhiko 5y agoselect() on windows is kinda fine. It uses an actual array in fd_set and you can increase the array length by defining a constant or passing a custom structure.
- swiley 5y agoYou might be surprised at how little standards like POSIX actually cover. There are huge gaps in the APIs implemented by e.g. QNX. (I haven't checked if this specifically is one of them but I would be surprised if it isn't.)
- shikoba 5y ago> the API should no longer be available for newly compiled code And break perfectly working code?
- WJW 5y agoArguably, if it depends on select() then it might unexpectedly break at runtime and is therefore not "perfectly working code".
- dspillett 5y agoAdd a switch to enable the previous behaviour. If the software is actually maintained than that switch will be added to the build config. If it isn't it shouldn't be used in production going forward. Whoever adds the option to the build process takes responsibility if the bugs it is deprecated to avoid do in fact affect this code.