This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FileDescriptor suggestion [Was: FYI: Patch: java nio file locking]


On Sun, Jan 25, 2004 at 12:08:41AM -0800, Per Bothner wrote:
> Michael Koch wrote:
> >I dont know how much possible this really is at first look. 
> >Note that java.net and socket stuff of java.nio are also using
> >FileDescriptor.
> 
> And SocketImpl has an actual protected fd field, which
> prohibits lazily allocating FileDescriptor at least for SocketImpl.
> 
> >> public FileDescriptor getFD ()
> >> {
> >>   return FileDescriptor.get(channel);
> >> }
> >
> >This has to be native code, otherwise we would get access violations or
> >compile time errors (depending on compiler)
> 
> Another problem I overlooked is garbage collecting FileDescriptors,
> which is difficuly when they're in a linked list.  Duh.  One
> could solve that using some kind of weak references, but that
> add more overhead than is justified.
> 
> So lets keep it simple:  Just add fields for FileDescriptor in
> the classes that need them.  FileDescriptor is simple wrapper
> around a FileChannel, and has no native methods:
> 
> public class java.io.FileDescriptor
> {
>   FileChannel channel;
>   ...;
> }
> 
> public class FileInputStream
> {
>   FileChannel channel;
>   FileDescriptor fd;
>   public getChannel () { return channel; }
>   public getFD ()
>   {
>     synchronized (this)
>       {
>         if (fd == null)  fd = new FileDescriptor(channel);
>         return fd;
>       }
>   }
> }

I dont really see why you wanna tie FileDescriptor so much to a
FileChannel object.

> 
> 
> >I more and more I think the idea from Anthony Green for
> >PlatformDescriptor gets more needed then ever. FileDescriptor would be
> >very minimal and all the platform dependant stuff would go into a
> >platform specific class.
> 
> But why not use FileChannel for this? I.e.:

If you really want PlatformFileDescriptor could inherit FileChannel.
I dont think that is a clean design.

> public class java.io.FileDescriptor
> {
>   FileChannel channel;
>   ...;
> }
> 
> public abstract class java.nio,channels.FileChannel { ... }
> 
> public abstract class gnu.java.nio.channels.FileChannelImpl
>   extends java.nio,channels.FileChannel { ... }
> 
> public abstract class gnu.java.nio.channels.FileChannelPosix
>   extends gnu.java.nio.channels.FileChannelImpl
> {
>   int fd;

Unfortunately even for Posix systems int is not enough, long would be
okay for 64 bit systems.

>   ...
> }
> 
> public abstract class gnu.java.nio.channels.FileChannelWin32
>   extends gnu.java.nio.channels.FileChannelImpl
> {
>   RawRata fd;

I think a long variable is enough on win32 too.

Of course I'm not sure about other OSes.

>   ...
> }
> 
> Thus FileChannelImpl is just another word for PlatformFileDescriptor,
> except that it happens to extend FileChannel.  Thus we avoid the
> overhead of having to have a separate PlatformFileDescriptor object.
> (The memory overhead doesn't matter, but it does require extra
> indirections we may want to minimize.)
> 
> The currently implementation has FileChannelImpl be a wrapper for
> FileDescriptor, and FileChannelImpl overations indirect to
> operations on FileDescriptor.  I'm suggesting we do the opposite,
> since there are so few public operations in FileDescriptor, but
> there are a lot in FileChannel, so we get better performance
> and simplicity having FileDesciptors operations indirect to
> operations on FileChannel.

Yes currently its implemented this way because it was easy to implement. 
I admit this. Its neither clean nor performant. I just works.


Michael


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]