Posix shared memory problem
scholz at scriptolutions.com
Mon May 11 09:29:54 UTC 2009
Sunday, May 10, 2009, 5:54:31 PM, you wrote:
GW> <<On Sun, 10 May 2009 07:57:06 +0200, Lothar Scholz
GW> <scholz at scriptolutions.com> said:
>> First of all you can't use '/' if you want stay portable.
GW> The Standard says otherwise.
It's not a standard think. Read about the real world programming
hints. You see recommendations to only use a starting '/'
>> It is also just a maximum of 13 char long (says the FreeBSD 6.X man page)
GW> Not in the manual page I have, and the Standard says otherwise.
This time you are right. It was about named semaphores and there
the limit seems to be removed - it was ridiculous low anyway.
GW> Again, the Standard says otherwise (or rather, it says that this is an
GW> implementation option). To quote the 2001 edition of the standard
GW> (XSH6 page 1313):
GW> It is unspecified whether the name appears in the file system
GW> and is visible to other functions that take pathnames as
GW> arguments. The name argument conforms to the construction
GW> rules for a pathname.
Thats why the man page calls this parameter 'name' and not 'path'.
Some idiots started to think about this as a file path. But it isn't
and it shouldn't. Thats what this spec is saying in the typical commitee
polite form when some members made a mistake but are to important to
be blamed in public.
So this needs to be fixed.
If i have to find a useable filefile location anyway the whole function does
not make any sense, then i can directly use mmap. The purpose is to
have a unique name (and in 2009 it is an URI not a file path). Thats
how serious non kiddy operating systems are doing like
And i guess also the accounting functions are wrong then. shm_open
does not open a file so the (internal used) file should not add to the
file space quota but to the memory allocation quota.
Lothar Scholz mailto:scholz at scriptolutions.com
More information about the freebsd-arch