On 28/02/14 14:40, Chris Hegarty wrote:
[ Volker: there are some trivial AIX changes here, maybe you could
verify them? ]
JDK-8021820 adds -D_DARWIN_UNLIMITED_SELECT to the build, but the
fd_set struct is still limited to 1024.
Snippet from man select(2):
"Although the provision of getdtablesize(2) was intended to allow
user programs to be written
independent of the kernel limit on the number of open files, the
dimension of a sufficiently
large bit field for select remains a problem. The default size
FD_SETSIZE (currently 1024) is
somewhat smaller than the current kernel limit to the number of
open files. However, in order
to accommodate programs which might potentially use a larger
number of open files with select,
it is possible to increase this size within a program by
providing a larger definition of
FD_SETSIZE before the inclusion of <sys/types.h>.
Either:
1) FD_SETSIZE needs to be set to a larger value, but what value, the
kernel limit, or other? This is wasteful for most typical apps that
don't use large numbers of file descriptors. Or,
2) If fd is greater than 1024, then an appropriate amount of memory
could be allocated and cast to an fd_set. The FD_SET macro will
write past FD_SETSIZE.
I think option 2 is preferable:
http://cr.openjdk.java.net/~chegar/8035897/webrev.00/webrev/
I'm still checking to see it an automatic regression test is possible,
but I wanted to circulate the changes for comment first.
Thanks,
-Chris.
I agree option 2 sounds better since adding (say) 4k * sizeof(fd_set) to
the stack is quite
significant given that it would rarely be required.
On the change itself I noticed one path in bsd_close.c NET_Timeout where
the malloc'd buffer
is not freed (line 418)
Is it potentially more efficient to use calloc() rather than malloc() +
memset()?
Maybe a test might need a shell script to call "ulimit -n 4096" or
something to be able to test it.
Michael
