purpose of FileDispatcher.preClose()

[Michael Allman]

On Wed, 30 Jan 2008, Alan Bateman wrote:

> Michael Allman wrote:
>> Hello,
>> 
>> Can someone with knowledge of such matters explain what 
>> FileDispatcher.preClose() is supposed to do on Solaris/Linux.  I mean, I 
>> see the code, but I don't understand why it exists or what problem it's 
>> supposed to avoid or something.
>> 
>> I ask because I'm trying to fix a file-locking problem on soylatte and it 
>> seems the solution to that problem is to remove this code (on that 
>> platform).  But before I charge ahead, I need a better understanding of why 
>> this code exists.
>> 
>> In particular, I'm really interested in the stuff that happens in 
>> FileDispatcher.c, functions Java_sun_nio_ch_FileDispatcher_init and 
>> Java_sun_nio_ch_FileDispatcher_preClose0.  They're setting something up 
>> that looks important, but I just don't get it.
> In a multi-threaded application it is always difficult to know when you can 
> safely close and release a file descriptor (or other resource). If one thread 
> is using a file descriptor to read or write and another thread releases 
> (closes) it then it it possible for the first thread to read or write to the 
> wrong file or socket in the event that the file descriptor is recycled 
> quickly. The approach that we use in both classic networking and NIO is to 
> use a two-step process. In the first step we duplicate (dup2) the file 
> descriptor to another that is one end of a half shutdown socket pair. Other 
> threads that are reading or writing but haven't called the read or write 
> system calls yet will get an immediate EOF or pipe error when they do so. As 
> the threads complete the read or write method then they examine their state. 
> If there is a close pending then the last one releases the file descriptor. 
> Hopefully this brief overview gives you some idea what this code is about. 
> The FileDescriptor#init method is where the socketpair is created, and that 
> preClose0 method does the dup2. I haven't been following the Soylatte port 
> very closely so I'm curious what problem you are seeing - when you say "file 
> locking" do you mean FileChannel#lock? If so then the issue may be that the 
> asynchronous close mechanism isn't completely extended to FileChannel yet.

I think I get it.  So let me explain the problem I'm seeing here.

If I close a file channel on which I have acquired (but not released) a 
file lock, I get an IOException: Bad file descriptor.  For example, the 
Lock regression test does this and fails (on soylatte).

I think the problem here is that FileChannelImpl.implCloseChannel() calls 
nd.preClose(fd) before the block that releases its file locks.  On 
non-windows, nd.preClose(fd) doesn't just "pre close" fd, it closes it. 
Then implCloseChannel() tries to release its file locks.  fd now points to 
a socket descriptor and on Solaris/Linux, such attempt seems to be 
harmless.  On Mac OS X, it complains with the EBADF error code.

It seems that the preClose semantics are not correctly handled by the 
FileChannelImpl.implCloseChannel() method.  On non-windows, it attempts to 
release file locks that no longer exist (because preClose() releases 
them).  It seems that the file lock release block should be moved into 
NativeDispatcher.preClose().  It will be run on Windows, but will not be 
run on non-Windows.  That seems correct to me, given that on non-Windows, 
preClose0 releases the file locks.

Obviously, this kind of change is much more than a soylatte patch.  It 
changes code that already works on Windows, Solaris, and Linux.  But if my 
analysis is correct, it looks like it's just a silent bug.

Thoughts?

Michael