4 ms·
> The kernel side interface probably won't change because apparently legitimate apps have been allocating fd_sets on the heap to monitor fds > 1024 and they don
by warpspin 3y ago
> The kernel side interface probably won't change because apparently legitimate apps have been allocating fd_sets on the heap to monitor fds > 1024 and they don't want to break those
Rightly so. Before libev, AIO or whatever where a thing, I used to run network servers 10 or 15 years or so ago with a redefined __FD_SETSIZE set to 16384 without any problems on Linux (plus appropriate proc and ulimit settings). The whole stack properly supported it, even if not officially supported.
The real problem nowadays is, people can easily receive a fd >= 1024 as you do not control them, and then put them into fd sets only supporting values up to 1023 and then you have a security problem. Plus of course, the later APIs also simply scale better beyond 16k connections.
- syncsynchalt 3y agoI'm guessing you didn't/couldn't use poll(2) because of the performance hit (both user and kernel side) of parsing/checking the less compact data structure? I both miss and don't miss the days before epoll(2) et al.
- warpspin 3y agoOriginally, we did not use it because it did not exist. That service existed already in a time before poll(2) was a thing on Linux and when we still had 256 fds only. The increase to 1024 and then to basically unlimited came just in time for us back then, and we were glad a simple recompile with a #define was all we needed to scale it. If my memory serves me right, we did try poll(2) though a while after it became available (and we already ran the 16k selects) but it was simply less performant. Later on, when java.nio came around and Java finally could "compete" for network services therefore, we switched from C to Java completely for that service.