RE: /dev/shm
"Howell, David P" <[email protected]>
| Newsgroups | gmane.linux.ngpt.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Alexandre, See my comments mixed in below with [DPH]. Thanks, Dave Howell -----Original Message----- From: Alexandre P. Nunes [mailto:[email protected]] Sent: Friday, June 28, 2002 10:55 AM To: [email protected] Subject: [pthreads-devel] /dev/shm Hi, I'm just new to ngpt. While trying ngpt-2.0.0, I figure out it requires (well, programs fails to run without) /dev/shm mounted, which I personally don't use. I've found quite a few programs which required it, and patched them to don't do it. I personally don't think a low level library, like ngpt, should. I did not look to the source code with the needed attention, but in a glimpse I think the created file in /dev/shm is them mmap()ed, right? Is there any other trick in it? Because if that's it, there are so many other options, which doesn't rely in mounting filesystems, like anonymous mapping, sysv shm (someone once told me that shmfs was used in his program because sysv shm was converted to shmfs, that is not true, the things aren't related at all). While the later maybe excluded from kernel compilation, anonymous mmap is always there, I guess shared anonymous mapping too. What about a threaded program, let's say a daemon, started right after booting and mounting the rootfs, but before the other filesystems? It may seems weird, but one may want/need to do it. Am I missing some point in here? [DPH] This is used for the shared mutex implementation, where more than one process group needs to be able to access a shared mutex. NGPT supports this and attaches a shared memory segment to manage the system wide shared mutexes, where each process instance of the NGPT runtime is looking for shared pathname to locate and attach to the shared mutexes. The ngptc utility initializes this area at SOD. I guess the need for a common path to look for the shared lock tables by potentially several NGPT runtimes, and the need to set it up at SOD makes the common pathname the alternative that was used for 2.0.0. Actually, with the SOD script provided this should be transparent. Another thing is the binary compatibility I posted in forum, does ngpt implements the cancellation point syscall mapping the glibc pthreads have? [DPH] This was discussed in a team meeting and I think was planned for later this fall. I will double check with Bill Abt on this and have it added if it isn't already on the list. Thanks, Alexandre _______________________________________________ pthreads-devel mailing list [email protected] http://www-124.ibm.com/developerworks/oss/mailman/listinfo/pthreads-devel