purpose of FileDispatcher.preClose()

[Alan Bateman]

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.

-Alan.