4 ms·
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 [wh
by henvic 3y ago
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!
- crest 3y agoDo you really consider 256 file descriptors a sane resource limit on processes?
- mmis1000 3y agoI 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?
- CodesInChaos 3y agoHaving 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.
- isodev 3y agoI believe it is given the risks of increasing the limit system-wide. Processes which really require more still have the option to ulimit/setrlimit.
- stephenr 3y agoDo you really think it's sane to write a program that just relies on the user increasing global limits, rather than calling setrlimit appropriately?
- CodesInChaos 3y agoAn 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?
- wiredfool 3y agoI hit the old limit of 512 in eMacs after a month or so.