Re: PATCH: remove all traces of java.io.FileDescriptor from java.net

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:

Jeff> a) create a new java.net.Socket, get fnum = 5, call new
Jeff> FileDescriptor(5).
Jeff> b) close the socket when done, and drop references so it is
Jeff> eligible for GC.
Jeff> c) create another socket, get fnum = 5 (since it is now available).
Jeff> d) the socket from a) is finally collected, and the corresponding fd is
Jeff> finalized, accidentally closing the socket we opened in c).
Jeff> e) any read/write on the socket created in c) returns EBADF.

Yeah :-(.  We've run into this problem in a few places now.  See my
Process fixes from a couple weeks ago.  A lot of care is required with
system file descriptors; both leaks and double closes cause real
problems.

Jeff> I suppose you could get around the problem by closing the fd in
Jeff> Socket.close(), except that FileDescriptor.close() may not do
Jeff> the right thing, so we really have to close twice.

The Sun API here sucks, because the FileDescriptor you get isn't
really usable.  You can't actually pass it to FileOutputStream, for
instance, due to system-specific differences in file descriptor types.

Or maybe what this means is that we're required to have
FileOutputStream recognize and automatically handle this difference?
We could do that with a flag in FileDescriptor.  Sounds ugly.

Meanwhile, I think we definitely must fix this bug for 3.1.  I
submitted a PR so we can track the issue.


You might think (I did :-) another way to fix this might be to add a
new method to FileDescriptor that would invalidate the object without
closing it.  However I think this won't work due to finalization
ordering problems.  If the Socket is finalized without an explicit
close, then the FileDescriptor finalizer might actually be run first,
causing us to call the wrong OS close function.

Jeff, if you don't have time to continue working on this, let me
know.  I have some time allocated to making 3.1 work.

Tom