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

[Bryce McKinlay]

Jeff Sturm wrote:

>>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 agree that it is incorrect. But how likely is this to occur? Does 
linux actually re-use closed file descriptor numbers like this? My 
recollection is that it doesn't (at least for a long time). But maybe 
I'm wrong.

>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?
>

It depends if there is code out there which uses them, and if so what it 
does with them. My guess is the only things that would care are things 
which define their own socket classes.

Then again, although it is ugly, I can't see any reason why it would 
make much difference whether we are using "fnum" or "fd->num" from the 
natPlainSocketImpl code (especially given that we don't have separate 
posix and win32 FileDescriptor classes)

>>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.
>

Maybe there are multiple bugs ;-)

regards

Bryce.