Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl

[Steven Augart]

Michael Koch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Dienstag, 11. Mai 2004 22:36 schrieb Steven Augart:
>
> > Michael Koch wrote:
> >
> > > Which leads us to the discussion again what type a file
> > > descriptor should have. Is an int (4 byte) enought for 64 bit
> > > archs ? What about 128 bit archs in the future ? From the last
> > > discussions fd should be at least long when. I know that GNU
> > > classpath currently uses int but when we change it we can try to
> > > do it right.
> >
> > Yes, an int is plenty of space.  It will always be plenty of space
> > unless you plan to be opening more than 2^31 files (and that
> > exceeds the limits of every Unix-like system that i know of).
> >
> > I should caution here that I don't have a copy of the POSIX spec.
> > However, the manual page for open(2) on Linux says:
> >
> >        The  open() system call is used to convert a pathname into
> >        a file descriptor (a small, non-negative integer  for  use
> >        in  subsequent  I/O  as with read, write, etc.).  When the
> >        call is successful, the file descriptor returned  will  be
> >        the lowest file descriptor not currently open for the pro-
> > -------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^­
> >        cess.
> >
> > This guarantee is part of historical Unix semantics
> > for open() -- there is still code around that (for example) closes
> > file descriptor 0 (standard input) and then opens some other file,
> > expecting that any successful open will assign descriptor 0 to
> > the opened file.
> >
> > So, if open() ever stopped handing out the lowest descriptor
> > it could, existing Unix code would break.
>
>
> What if someone wants to port GNU classpath to an Operating System 
> with totally different semantics like Windows ?

If someone does that kind of port, he'll have more problems than just
than the size of a file descriptor.  I am not a big fan of writing
massively general code "just in case."  The Extreme Programming series
of books talks about this too.  "Sufficient unto the day is the evil
thereof."

It is nice to uses abstraction -- if we were running a preprocessor
over Classpath's code then I would favor using a named type called
something like filedesc_t which will turn into "int" on all of the
platforms we currently run on -- but there is not consensus in favor
of preprocessing our Java right now, and Java lacks any "typedef"-style
mechanism for handling this sort of thing.

I don't know what type the Win32 API uses for a file descriptor; I
have a vague memory of it also being a small integer, but this may be
wrong.  In any case, I think that someone doing such a port would propose
an appropriate change at the time of the port.

This is also why I was not a big fan of using byte[] to
represent pointers just so that we could possibly be compatible
with a system that no Classpath users were actually running.
In my Classpath code that interacts with C, I represent a C pointer
as a Java "long".  That wastes 32 bits on the machines that I am
running classpath on, but it works.  When we go to new kinds of machines,
we'll deal with the problems as they come up.

--
Steven Augart

Jikes RVM, a free, open source, Virtual Machine:
http://oss.software.ibm.com/jikesrvm