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

[Michael Koch <konqueror at gmx dot de>]

On Fri, Jan 23, 2004 at 05:45:34PM -0800, Per Bothner wrote:
> I looked at Sun's JavaDocs for FileDescriptor, and as far as I can
> tell it isn't actually useful for much.  To implement streams we
> should we use nio's FileChannel.  We just need File Descriptor for
> backwards compatibility.  Here is (a sketch of) an implementation that
> defers creating FileDescriptor objects until needed.  It doesn't even
> use a field in other objects; it just maintains a global mapping
> from FileChannelImpl to FileDescriptor.  The mapping is simple
> linked list, with the most recently accessed items first.
> 
> There would be no native code for FileDescritor; all the
> native code woudl be in FileChannelImpl.
> 
> Is this a reasonable approach?

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.
> 
> public class FileInputStream
> {
>   FileChannelImpl channel;
> 
>   public FileInputStream (FileDescriptor fd)
>     throws SecurityException
>   {
>     SecurityManager s = System.getSecurityManager();
>     if (s != null)
>       s.checkRead(fd);
> 
>     channel = fd.channel;
>   }
> 
>   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)
>   ...
> }
> 
> public class FileDescriptor
> {
>   private static FileDescriptor descriptors = null;
>   public static final FileDescriptor in = get(FileChannelImpl.in);
>   public static final FileDescriptor out = get(FileChannelImpl.out);
>   public static final FileDescriptor err = get(FileChannelImpl.err);
> 
>   private FileDescriptor next;
>   private FileChannelImpl channel;
> 
>   // This constructor is specified to create an invalid descriptor.
>   public FileDescriptor ()
>   {
>     get(new FileChannelImpl());
>   }
> 
>   static synchronized FileDescriptor get(FileChannelImpl channel)
>   {
>     FileDescriptor prev = null, cur = descriptors;
>     while (cur != null)
>       {
> 	if (cur.channel == channel)
> 	  {
> 	    if (prev != null)
> 	      {
> 		// Move to front.
> 		prev.next = cur.next;
> 		cur.next = descriptors;
> 		descriptors = cur;
> 	      }
> 	    return cur;
> 	  }
> 	prev = cur;
> 	cur = cur.next;
>       }
>     cur = new FileDescriptor();
>     cur.channel = channel;
>     cur.next = descriptors;
>     descriptors = cur;
>     return cur;
>   }
> 
>   public void sync () throws SyncFailedException
>   {
>     channel.sync();
>   }
>   public boolean valid ()
>   {
>     return channel.valid();
>   }
> }

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.

http://mail.gnu.org/archive/html/classpath/2003-04/msg00092.html

I think thats the start of the discussion about it.

When we change FileDescriptor's behaviour we need to talk about this
with the classpath people too because we share the implementation of
classes using FileDescriptor and they would be "affected" too ;-).


Michael