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

[Per Bothner <per at bothner dot com>]

Mohan Embar wrote:

> Hi Per,
>
>
> > How about this:
> >
> > class FileDescriptor
> > {
> >  Channel channel;
> >  public void sync () throws ...
> >  {
> >    if (channel instanceof FileChannel)
> >      ((FileChannel) channel).force(true);
> >  }
> >  public boolean valid () { return channel.isOpen(); }
> > }
>
>
> I like this! So where would the platform-specific subclasses similar
> to PlatformFileDescriptor come into play?

There wouldn't be any for FileDescriptor, since it has no native
methods.  All the stuff that used to be there would instead be
in gnu.java.no.channels.natFileChannel*.cc.

And how would getFD()
> and getChannel() look in FileInputStream?

  private FileDescriptor fd;

  private FileChannel ch;

  public synchronized final FileDescriptor getFD() throws IOException
  {
    if (fd == null)
      fd = new FileDescriptor (ch);
    return fd;
  }
  public synchronized FileChannel getChannel ()
  {
    return ch;
  }
  public FileInputStream(FileDescriptor fdObj)
  {
    SecurityManager s = System.getSecurityManager();
    if (s != null)
      s.checkRead(fdObj);

    fd = fdObj;
    channel = ((FileChannel) fdObj).channel;
  }

(The type of ch might have to be a FileChannelImpl
if FileInputStream needs methods specific to the former.)

> Why int? For me, an int is a quantity. That's not to say that someone's not
> allowed to typedef to an int as an implementation detail, but exposing a raw
> int datatype in all its glory for something other than a quantity seems a breach
> of encapsulation to me. C has had "typedef" from day one, so in my mind,
> there was no excuse for this.

It's still an int or a pointer.

A Posix file descriptor is an "unforgeable pointer" into kernel space.
I.e. it's an index into a kernel table.

> > > (Of course, Windows has these too for its POSIX-lookalike API functions,
> > > and I don't even want to think about what kinds of funky mapping they're
> > > doing under the covers to make this work.)
> >
> > An array?
>
>
> Probably, but one array where the index is the int? Or two arrays where one contains
> the int and the other the handle? Both solutions require the unnecessary global
> synchronization that this approach entails.

You only need synchronization if you have threads.

> (Or are they doing this some other way,
> like casting the pointer to an int, but I don't think so because there's a special function
> for getting the OS handle for such an int file descriptor, but maybe they did this to
> encapsulate the typecast - aaaaaargh!).

That's not possible, since Posix compatibility requires that 0/1/2
be stdin/stdout/stderr.  Plus you have 'dup', so just casting handles
doesn't work.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/