Bug in interrupt handling in FileChannelImpl.map(…)

[Alan Bateman]

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.