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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.