You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some systems set an artificially low soft limit on open file count,
for compatibility with code that uses select and its hard-coded
maximum file descriptor (limited by the size of fd_set).
Go does not use select, so it should not be subject to these limits.
On some systems the limit is 256, which is very easy to run into, even
in simple programs like gofmt when they parallelize walking a file tree.
After a long discussion on go.dev/issue/46279, we decided the best
approach was for Go to raise the limit unconditionally for itself, and
then leave old software to set the limit back as needed. Code that
really wants Go to leave the limit alone can set the hard limit, which
Go of course has no choice but to respect.
Take 2, after CL 392415 was rolled back for macOS and OpenBSD failures.
The macOS failures should be handled by the new call to sysctl("kern.maxfilesperproc"),
and the OpenBSD failures are handled by skipping the test (and filing #51713).
Fixes#46279.
Change-Id: I45c81b94590b447b483018a05ae980b8f02dc5de
Reviewed-on: https://go-review.googlesource.com/c/go/+/393354
Trust: Russ Cox <[email protected]>
Reviewed-by: Bryan Mills <[email protected]>
Run-TryBot: Russ Cox <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
0 commit comments