Date: Mon, 11 May 2009 11:25:37 +0200 From: Lothar Scholz <scholz@scriptolutions.com> To: Garrett Wollman <wollman@bimajority.org> Cc: arch@freebsd.org Subject: Re[2]: Posix shared memory problem Message-ID: <1393224851.20090511112537@scriptolutions.com> In-Reply-To: <18950.63671.323324.756287@hergotha.csail.mit.edu> References: <mit.lcs.mail.freebsd-arch/588815840.20090509203115@scriptolutions.com> <mit.lcs.mail.freebsd-arch/20090509200724.GA25714@stack.nl> <200905100500.n4A50GOa050728@hergotha.csail.mit.edu> <7710650619.20090510075706@scriptolutions.com> <18950.63671.323324.756287@hergotha.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Garrett, Sunday, May 10, 2009, 5:54:31 PM, you wrote: GW> <<On Sun, 10 May 2009 07:57:06 +0200, Lothar Scholz GW> <scholz@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 Linux/Solaris/MacOSX-Darwin/HP-UX. 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. -- Best regards, Lothar Scholz mailto:scholz@scriptolutions.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1393224851.20090511112537>