On Monday 30 July 2007 2:11:18 am Carlo Zinato wrote: > Arnar Mar Sigurðsson ha scritto: > > Is there any work being done to bring POSIX shared memory support to > > uclibc? (shm_open and shm_unlink) > > Hi Arnar, > > You may read this thread: > > http://www.uclibc.org/lists/uclibc/2006-December/017027.html > > I had the same problem, and I successfully use /tmp (ram filesystem) to > exchange blocks of data between processes.
I'm still a bit behind from my move, but I point out that User Mode Linux used to use /tmp and assume it had tmpfs mounted on it, and that this is NOT necessarily the case, and no spec requires it. If it doesn't have tmpfs mounted on it (PLD linux, case in point) then dirtying lots of pages in there means you're constantly writing to disk which is the nastiest thing you can do to the block layer and kills system performance in a big way. However, /dev/shm is where the LSB FHS demands an instance of tmpfs. A system that doesn't have a tmpfs mounted there probably won't have that directory, so it's a darn easy error to detect. (Yes, modern shared memory is just an mmap of a file in a tmpfs mount, and any other semantics layered on top of that are implemented that way deep down. Way back when, before tmpfs was invented, you'd open a file, mmap it, and then delete it, and the page cache knew to stop flushing pages to disk for an inode with a filesystem refcount of zero because it would go away when closed. Still allocated blocks out of the filesystem and thus took up space on disk, of course, but it worked. Alas, Linux took out the check for a deleted inode in the page cache flush when tmpfs went in, so pulling that trick on /tmp can drive your system into disk thrashing if it isn't tmpfs.) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
