[erlang-questions] Fix for bogus {error, enfile} from gen_tcp:accept/1, 2

[Per Hedeland]

Hello,

CC'ing erlang-questions since this bug has caused some confused
discussions in the past, with well-meaning info from people (including
me) that know something about what ENFILE means mostly adding to the
confusion.

The R12B-0 release README says:

OTP-6968  If open_port fails because all available ports are already in
          use, it will now throw a system_limit exception instead of an
          enfile exception. (enfile might still be thrown if the
          operating system would return ENFILE.)

Which is great (and it shouldn't have been enfile in the first place),
but gen_tcp:accept/1,2 which is probably the most common cause of
running out of (Erlang) ports has continued to return {error, enfile}
when the actual problem is that all ports are in use. The problem is a
bit elusive, since at least on Unix, the port table is sized based on
the OS process file descriptor limit - i.e. you may well get {error,
emfile} (note the 'm'!:-) before you run out of ports - unless you have
driver instances that use ports without using file descriptors. So:

Fix returned error from gen_tcp:accept/1,2 when running out of ports

The {error, enfile} return value is badly misleading and confusing for
this case, since the Posix ENFILE errno value has a well-defined meaning
that has nothing to do with Erlang ports. The fix changes the return
value to {error, system_limit}, which is consistent with e.g. various
file(3) functions. inet:format_error/1 has also been updated to support
system_limit in the same manner as file:format_error/1.

  git fetch git://github.com/perhedeland/otp.git fix_enfile

(Hoping that I didn't mess up the git stuff.:-)

--Per Hedeland
per@REDACTED