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

Jeff Sturm jsturm@one-point.com
Sun Mar 24 22:35:00 GMT 2002


On Mon, 25 Mar 2002, Bryce McKinlay wrote:
> I agree that it is incorrect. But how likely is this to occur? Does 
> linux actually re-use closed file descriptor numbers like this?

Linux seems to always allocate the next-unused fd, so it is easy to
reproduce this.  It would probably be easy to concoct a reliable test
case.  (But even if that were not the case there are a lot of kernels
besides Linux to worry about.)

I traced java.io activity to see this for myself (which also exposed some
interesting ResourceBundle behavior that'll be a topic for another day).

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

I have no idea.  I can't think of many interesting uses for fd, except
perhaps if Sun had tried to reuse FileInputStream/FileOutputStream for
sockets (note I'm not saying they did).  Especially considering the
(un)portability of it.

If I cared I would probably file a bug with Sun.  But to be honest I
really don't give a hoot about their API.

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

That's one workaround, just do "fd->num = -1" in SocketImpl.close().

I don't really care.  But I think it's imperative that this is fixed
somehow in 3.1.

> >I don't think it's relevant, but I ran with GC_IGNORE_GCJ_INFO in any
> >case.
> 
> Maybe there are multiple bugs ;-)

Very likely.  I still experience random deadlocks without
GC_IGNORE_GCJ_INFO, similar to what you reported on GCTest.  Thread-local
allocation doesn't seem to have any effect on that.

Jeff



More information about the Java-patches mailing list