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

[Chris Hegarty]

On 28 Feb 2014, at 17:28, christos at zoulas.com wrote:

> 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:

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