Yes, it's hardcoded. FD_SETSIZE should be the maximum number of file descriptors you can ever have open. On my Linux box here, FD_SETSIZE is 1024, and I can't ulimit -n any more than this. Cheers, Simon On 27 October 2005 15:18, Joel Reymont wrote:
Actually, I think I was just hitting the top range of FD_SETSIZE, about 8000 on that machine.
Does FD_SETSIZE get hardcoded into ghc-built binaries? That is if I increase the available descriptors per process with uname -n, will it be taken into account?
Thanks, Joel
On Oct 26, 2005, at 10:04 AM, Simon Marlow wrote:
lockFile uses FD_SETSIZE as its idea of the maximum value of a file descriptor. If you can get file descriptors outside this range, then the above error would ensue. Not sure if this is the case on FreeBSD... seems odd if it is. Can you try a truss/ktrace and see the values of your file descriptors?
Understood. I had the same problem with Erlang on Mac OSX and had to edit system files to bring it up to the maxium allowed of 10240. Worked like a charm after recompiling. What do you do on Windows where there's no hard-coded FD_SETSIZE? On Oct 28, 2005, at 9:14 AM, Simon Marlow wrote:
Yes, it's hardcoded. FD_SETSIZE should be the maximum number of file descriptors you can ever have open. On my Linux box here, FD_SETSIZE is 1024, and I can't ulimit -n any more than this.
2005/10/28, Joel Reymont
Understood. I had the same problem with Erlang on Mac OSX and had to edit system files to bring it up to the maxium allowed of 10240. Worked like a charm after recompiling.
What do you do on Windows where there's no hard-coded FD_SETSIZE?
For quite a long time the file locking was broken on Windows and the files were not locked at all. After the last major GHC release the files are locked using the Win32 API and the lockFile hack isn't required. Cheers, Krasimir
My main question is where the FD_SIZE limit applies to the number of sockets that I can open. Does it? I would assume this does not need to be hardcoded. On Oct 28, 2005, at 11:11 AM, Krasimir Angelov wrote:
For quite a long time the file locking was broken on Windows and the files were not locked at all. After the last major GHC release the files are locked using the Win32 API and the lockFile hack isn't required.
participants (3)
-
Joel Reymont -
Krasimir Angelov -
Simon Marlow