Bug in interrupt handling in FileChannelImpl.map( … )

[Chris Dennis]

I'll look in to the test when I get a chance.  I haven't seen it fail this
way - but like I said the close logic is a bit weird in order to try and
make the failure 'clean'.  I'll look through it and see if I can figure
out what might be going wrong.

Chris

On 10/15/13 11:47 AM, "Alan Bateman" <Alan.Bateman at oracle.com> wrote:

>On 23/09/2013 14:33, Chris Dennis wrote:
>> Sure, no problem. There are a couple of oddities to note in the test…
>>
>> 1. It doesn't actually end up mapping anything. I'm intentionally trying
>> to extend the file from zero length to length one, when the file is
>> read-only.  This way I pass through the nested size call, but don't
>> actually end up mapping anything.  Seemed to me like this was the
>>simplest
>> way to test exactly this bug and nothing else, and also avoid all the
>> windows specific mapping behaviors causing any problems.
>> 2. I'm not closing the file in a finally block because when the code is
>> broken the locking will block the close call, hence I'm only closing on
>>a
>> successful run.
>>
>Just coming back to this. The patch to FileChannelImpl.map looks fine
>(and the update to when map needs to extend the file is okay too). I'm
>happy to sponsor this and get it in.
>
>I'm not sure about the test yet, it appears to fails intermittently (on
>several platforms), typically because the FileChannel isn't closed. Have
>you seen this? I haven't dug into it yet but we would need the test to
>be very reliable to include it with the patch.
>
>-Alan.
>
>