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

[Aleksej Efimov]

Alan, Tim,

I have addressed your comments and as a result - new webrev:
http://cr.openjdk.java.net/~aefimov/8021820/webrev.01

The list of changes:
1. The connection to Oracle site is removed (it's not internal, but 
anyway it's better not to rely on availability of external resource in 
test). In current version a server socket is created and accept() method 
is used for bug disclosure.
2. The cleanup method is added for closing file streams. The JTREG 
successfully cleaned-up on windows after this modification.
3. common/autoconf/toolchain.m4 untouched, but 'bash 
common/autoconf/autogen.sh' was executed to update generated-configure.sh.

Aleksej


On 07/31/2013 06:35 PM, Tim Bell wrote:
> 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.
>