[erlang-questions] {error, emfile} on windows

[Matthew Sackman]

On Tue, Nov 30, 2010 at 03:08:33PM +0100, Kenneth Lundin wrote:
> See the documentation at:
> http://www.erlang.org/doc/efficiency_guide/advanced.html#id64904
> (I admit that it is not easy to find this, but the Efficiency Guide is
> important to know about and to read through for all system builders)

Interesting - I've read that several times before ... except clearly not
the bits about ports and sockets. Thanks for the pointer.

Could you clarify the documentation a bit though - for example, on my
Linux machine, I have a ulimit -n of 100000 and I don't seem to need to
configure anything further (certainly I've never touched ERL_MAX_PORTS)
for Erlang to be able to use many sockets and fds.

Thus for platforms which have an Erlang port and ulimit, which of the
ulimit -n and ERL_MAX_PORTS is used if both are set?

> We are thinking of changing this to a totally dynamic number of ports
> only limited by the OS setup, but that work is not scheduled for a
> specific release yet.

So under Windows, various sources eg
http://blogs.technet.com/markrussinovich/archive/2009/09/29/3283844.aspx
suggest that the limit is 16M. You've suggested that unnecessarily high
numbers are likely to waste memory, so would the limit be detected and
set dynamically at startup or would memory only be allocated as needed?

Also, under unices, file descriptors and sockets come from the same
pool, but under Windows, my understanding is that this is not the case.
Could you confirm that in the Windows port, file descriptors are win32
file handles, and sockets are winsock socket handles? Is there going to
be a supported+documented API to be able to inspect the limits of each
and the number of each allocated that works on both Windows and unices?

> > Whilst in theory windows has a limit of around 16M fds per process, the
> > Erlang windows port seems to use bits of the MS C runtime. This seems to
> > limit severely wrt number of available sockets.
> 
> Well this is not a correct statement as already described.

Indeed not. Thanks for the illumination.

Matthew