[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: |
Michael Koch |
Subject: |
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl |
Date: |
Tue, 11 May 2004 22:56:36 +0200 |
User-agent: |
KMail/1.5.4 |
-----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 ?
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAoT4FWSOgCCdjSDsRAh9KAJ9dTcmLutgZ2J15tDQNdgb766No4QCfb+ls
eD0Jn1YYAA82ImQynrzpUiQ=
=i97K
-----END PGP SIGNATURE-----
- gnu.java.nio.channels.FileChannelImpl, David P Grove, 2004/05/10
- Re: gnu.java.nio.channels.FileChannelImpl, Michael Koch, 2004/05/11
- Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl, Steven Augart, 2004/05/11
- Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl, Anthony Green, 2004/05/12
- Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl, Steven Augart, 2004/05/12
- Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl, Anthony Green, 2004/05/12
- Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl, Steven Augart, 2004/05/12
- Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl, Per Bothner, 2004/05/12
[Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl, Eliot Moss, 2004/05/20