RE: MIT shared memory extension

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

> -----Original Message-----
> From: Ralf Habacker [mailto:Ralf.Habacker@freenet.de] 
> Sent: Tuesday, May 07, 2002 7:41 AM

> What about using a new type respective casts for cygdaemon. 
> This would not break key_t compatibility and allows to 
> migrate single application to cygdaemon, while others works 
> with cygipc (at least for a limited time) ?

At the moment key_t's are generated locally without the cygserver. This
means that in theory a cygipc linked app will still work with the new
key_t code after recompiling (I think we do need to remove ftok from
cygipc at that point though). If we have a list of key_t's, then it must
be global, so cygserver will have to be running. I think that that is
bad.
 
Also at the moment, we know that the same file will generate the same
key_t every time. (because it's inode based). 

If we walk a list, then we'll have to walk the entire list *and store
the file name the key was generated from* to see if it's been handed out
already. Lastly we don't have an existing list of key_t's, that was a
list of shm areas you are referring to, and they can share the key_t
values. (the shmid is the index in that list).

In short, I don't like the idea of making key_t 32 bits.

Rob