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