Date: Mon, 11 May 2009 16:40:27 +0530 From: Sujit K M <kmsujit@gmail.com> To: Lothar Scholz <scholz@scriptolutions.com> Cc: arch@freebsd.org, Garrett Wollman <wollman@bimajority.org> Subject: Re: Re[2]: Posix shared memory problem Message-ID: <74fe56020905110410y430bf76yacf5c5a308a99865@mail.gmail.com> In-Reply-To: <1393224851.20090511112537@scriptolutions.com> 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> <1393224851.20090511112537@scriptolutions.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Any sort of frustration here? > 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. > What ever the Idiots are saying is correct. Read up some decent Unix manual. > So this needs to be fixed. What needs to be fixed? Could you be more specific? > 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. Try using these giant, great, long lasting things. > > 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. I think you need a check up. You seem to be contradicting what ever you said before.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?74fe56020905110410y430bf76yacf5c5a308a99865>