Re: /dev/shm

Howell, David P wrote:

>Hi Alexandre,
>See my comments mixed in below with [DPH].
>
>Thanks,
>Dave Howell
>
>[snip]
>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. 
>  
>

It seems like the wheel reinvented the from other way. I've seen mutexes 
to manage shared memory, but shared memory to manage mutexes is a funny 
thing, at least. I'm not saying it's wrong, but it seems strange at a 
first look.

Well, a mapping could be done to any file on any filesystem, an example 
could be /tmp/ngpt. chroot environments generally have /tmp.

But I see at least one problem using this scheme and variations:

- User processes may intentionally disturb the file, and cause programs 
owned by other users, including root, to misbehaving; Bot /dev/shm and 
/tmp have mode 1777, it can't be changed since we cannot monopolize the 
system directories permissions. The directories permission don't mean 
much if the system correctly creates the file at boot. But the files 
themselves should have a world-writable mode or else we couldn't map 
them the right way, since users also use threads, in  my case more than 
the super user. If the disturb reflects to the mapping  (and I guess it 
does at least if there's no previous mapping attached), then it's a bad 
thing anyway. But, in fact, we cannot run away easily from this problem, 
since there's always a shared memory need which must be accessible by 
all users, even if there's no file at the backend.

It seems all weird anyway. We have sysv ipc semaphores, file (inode) 
level locking, and now shared mutex stuff. Oh well, better too many than 
too few.

>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.
>
>  
>
Ok. I recompiled mysql anyway, It worked just fine, until I asked it to 
shutdown, them it printed messages about forcing threads to exit (which 
I suspect is related to cancellation points anyway), and then hungup. I 
had to kill with -9 on it.

Thank you again,

Alexandre