[SciPy-user] shared memory machines

Philip Semanchuk philip@semanchuk....
Mon Feb 9 14:25:57 CST 2009

On Feb 9, 2009, at 1:05 PM, Sturla Molden wrote:

> On 2/9/2009 6:49 PM, Philip Semanchuk wrote:
>> If you're destroying the segment when the attach count drops to zero,
>> why not check that immediately after the call to shmdt()?
> I thought it was only the owner/creator that was allowed to do that?

Yes, sort of. Sys V IPC objects are owned by users, not processes, so  
if user foo creates a semaphore in one process and destroys it in  
another, that's OK. I just verified this on OS X. Unless portions of  
your SciPy application will be running under different users, I think  
the matter of which process destroys an IPC object is irrelevant.

>> ftok() should probably be avoided as it returns duplicate keys:
>> http://nikitathespider.com/python/shm/#ftok
> Oh :(
> In that case I could rewrite the object to pickle the shmid instead  
> of a
> random name (uuid string) on System V.

But you need the key, not the id, to pass to shmget() to get a handle  
to an existing IPC object.

>> I'd recommend using a random number generator instead. I believe a
>> key_t is guaranteed to fit into an int, so you could generate a  
>> random
>> number anywhere from 1 to INT_MAX, taking care not to step on the
>> value IPC_PRIVATE (unless you want to assume that that is always
>> #defined to 0).
> I am not sure how big the problem is, as I pass an uuid as filename  
> to ftok.

I'm not sure how big the problem is either. All I know is that in my  
experience, ftok() returned the same key for different files in the  
same directory. I realized, therefore, that my code needed to handle  
the case where ftok() didn't generate a useful key. Since I needed a  
second, more reliable method of key generation, why use ftok() at all?

If I were you, rather than trying to figure out how broken ftok() is  
(and it might be broken in different ways on different platforms), I'd  
just abandon it altogether. It's not as if generating a random number  
instead is difficult. In fact, it's easier. Instead of generating a  
random uuid and passing that to ftok(), eliminate the middleman and  
generate a random key yourself.

More information about the SciPy-user mailing list