|
From: | Steven Augart |
Subject: | Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl |
Date: | Tue, 11 May 2004 17:34:13 -0400 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |