RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx]

[Tim Bell]

Aleksej, Alan

The change in common/autoconf/toolchain.m4 looks correct to me, and I 
think that is a good place to have it.  Remember to run 'bash 
common/autoconf/autogen.sh' and check in the generated-configure.sh 
files as part of the changeset.

I didn't look at the test case, but I think Alan has some good points.

Tim

On 07/31/13 06:45 AM, Alan Bateman wrote:
> On 31/07/2013 05:18, Aleksej Efimov wrote:
>> Hi,
>> Can I have a review for the following problem:
>> The MACOSX JDK (more precisely - the java.net classes) uses the 
>> select() system call to wait for different events on sockets fds. And 
>> the default behaviour for select() on Darwin is to fail when fdset 
>> contains the fd with id greater than FDSET_SIZE(=1024). Test case in 
>> webrev illustrates this behavior.
>> There is at least one solution for it: use -D_DARWIN_UNLIMITED_SELECT 
>> compilation flag for all macosx sources: this won't affect other 
>> parts of JDK because they are not using select().
>> Currently, I have added this compilation flag to 
>> common/autoconf/generated-configure.sh and 
>> common/autoconf/generated-configure.sh. I wonder, if there is a 
>> better place where I can put this flag?
>>
>> The webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.00/
>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021820
>
> Thanks for looking into this one. The build changes look okay to me 
> but it's probably best that someone on build-dev agree to those.
> Michael McMahon can probably explain why the net code is using select 
> for timed read/accept (I have a vague recollection of there being an 
> issue with poll due to the way that it is implemented on kqueue with 
> the result that it had to be changed to use select).
>
> I think the test needs re-work. It looks to me that the it attempts to 
> connect to an Oracle internal site so that's not going to work 
> everywhere. In general we don't want the tests to be dependent on 
> hosts that may or may not exist (we had tests that used to this in the 
> past but they caused a lot of grief). It also looks like the test 
> doesn't close the 1023 files that it opens at the start and so I 
> assume this test will always fail on Windows when jtreg tries to 
> clean-up.
>
> -Alan.