Hacker News Reader

Comment by henvic | Hacker News Reader

Globals are a nightmare. Despite this being something really common to do for developers and something that will cause a pain for a lot of early adopters of [whatever software that requires it], I see this as a great move!

View on HN

Do you really consider 256 file descriptors a sane resource limit on processes?

I hit it because i use ssh to tunnel connections to mac. And sshd seems to use file socket to handle the sessions. I honest don't think it is a sane limit at 2023. Even the most complained 'low performance' platform like nodejs handles thousands of connections just fine. What it the point to have a limit of 256?

Having a soft-limit of FD_SETSIZE (typically 1024) prevents memory corruption in applications using `select`. The hard-limit is generally huge (>100k) so applications which don't need that protection can simply raise their soft-limit.

I believe it is given the risks of increasing the limit system-wide. Processes which really require more still have the option to ulimit/setrlimit.

Do you really think it's sane to write a program that just relies on the user increasing global limits, rather than calling setrlimit appropriately?

An application that opens many files and doesn't use `select`, should raise its own soft-limit to match the hard-limit (or a reasonable number below the hard limit, if it wants to self-limit for some reason).

The default soft-limit should match FD_SETSIZE and should not be raised globally by the user. I don't know why the default hard limit is 256 and not 1024. Perhaps FD_SETSIZE was lower than 1024 historically?

I hit the old limit of 512 in eMacs after a month or so.

Reply on news.ycombinator.com