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

[Jeff Sturm]

On Mon, 25 Mar 2002, Bryce McKinlay wrote:
> >
> >2002-03-24  Jeff Sturm  <jsturm@one-point.com>
> >
> >	* java/net/DatagramSocketImpl.java
> >	(java.io.FileDescriptor): Don't import.
> >	(fd): Remove instance variable.
> >	(getFileDescriptor): Remove method.
> >
> 
> I don't think we can do that: both "fd" and getFileDescriptor() are part 
> of the API.

Ah, yes... I see that now.  I think that's a mistake in the API.  Oh well.

> Probibly the "fnum" field in PlainSocketImpl should go away, not "fd".

But file descriptors != sockets.  The fnum field was introduced to fix
that, I think... among other problems, the read/write/close methods in
FileDescriptor Just Don't Work on e.g. win32 sockets (and probably other
socket libraries I don't know about).

> I don't see how we could be getting premature finalization here.

I think I do, now that I've thought about it some more.  The
current code is wrong.  Consider:

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

The last is the problem I reported earlier on java@gcc.gnu.org.  It wasn't
altogether easy to track down. :-/

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

Or just not use FileDescriptor, like I proposed.  Would it be a violation
of the API if we left in fd/getFileDescriptor but didn't use them at all?

> Can you verify that the bitmap GC descriptor for SocketInputStream is 
> correct?

I don't think it's relevant, but I ran with GC_IGNORE_GCJ_INFO in any
case.

Jeff