[ On Wednesday, July 9, 2003 at 15:21:43 (-0400), der Mouse wrote: ]
quoted text
> Subject: Re: fsync performance hit on 1.6.1
>
> Maybe, maybe not, but your example is irrelevant - inumbers are _not_
> the API-visible namespace for filesystems!

Anyone who ignores the fact that unix filesystems are inherently flat
namespaces at their lowest level does so at his or her own peril!  ;-)
Directories are just files full of names and pointers to the true
numerical namespace of the filesystem.

quoted text
> > ftok() _should_ always create a unique key to match any unique file
> > and 'id' parameter (and of course _should_ always return the same key
> > for the same file & 'id').
> 
> Which implies that no conformant OS on a machine with 32-bit ints can
> ever support as many as 2^24 files simultaneously accessible.

What gives you that idea?

The standards do not specify what a "key_t" is.  P1003.1-2001 says only
that it is "Used for XSI interprocess communication" and that it is
defined by including <sys/types.h>.

For all you know at the API level of ftok(), shmget(), semget(), and
msgget() a key_t could be a struct, or a pointer to a struct, containing
a full copy of a "struct stat" along with a full copy of the stat()ed
pathname in a char array and a copy of the whole int-sized 'id' value.
(and that's probably what it should be, without perhaps the pathname)

The resulting IPC resource descriptors returned by shmget(), msgget(),
and semget(), each being in its own namespace and each being defined as
type 'int' with "-1" being a reserved value, allows, strictly speaking,
for UINT_MAX-1 open resources of each type, along with UINT_MAX-1 open
ordinary files (though practically speaking it's INT_MAX for each of
course because so many programmers assume all negative values are
equivalent to "-1").

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>