On 28 Feb 2014, at 17:28, chris...@zoulas.com wrote: > 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:
We are using select on OS X, only, because of a bug in poll, see https://bugs.openjdk.java.net/browse/JDK-7131399 Michael ran into this in the original OpenJDK Mac port. -Chris. > > 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
