RFR [9] 8035897 : FD_SETSIZE should be set on macosx

[Christos Zoulas]

On Feb 28,  3:55pm, michael.x.mcmahon at 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