On Feb 28, 3:55pm, michael.x.mcma...@oracle.com (Michael McMahon) wrote: -- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx
| 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. Can we instead please switch to poll? Select is problematic for many reasons: 1. Expensive because you need do operations on bitmasks [ffs/shifts]. 2. Expensive because you need to reset the masks before each call. 2. Can only report 3 types of events, read/write/except. 4. Non portable behavior for >= 256 fd's. All systems need source recompilation; some older systems need kernel recompilation. 5. Non-portable behavior with respect to ERESTART; it is unspecified what happens when the interrupting signal has SA_RESTART set. 6. Non-portable behavior when running out of resources. The only way to fix this is using non-blocking-io which is a bit of a pain. 7. Non-portable behavior with respect to "struct timeval *timeout". This is non-const, and it was originally intended to return the time left. Most implementations did not change "timeout", but one or two did, so it is always good to re-initialize "timeout". 8. Non-portable behavior as to the maximum timeout value supported. 9. Non-portable behavior for descriptor types other than regular files and sockets christos