[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
From: |
Steven Augart |
Subject: |
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl |
Date: |
Tue, 11 May 2004 16:36:19 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 |
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.
--
Steven Augart
Jikes RVM, a free, open source, Virtual Machine:
http://oss.software.ibm.com/jikesrvm
[Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl, Eliot Moss, 2004/05/20