This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
RE: MIT shared memory extension
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- To: "Ralf Habacker" <Ralf dot Habacker at freenet dot de>,"Cygwin-Xfree" <cygwin-xfree at sources dot redhat dot com>
- Date: Tue, 7 May 2002 08:31:04 +1000
- Subject: RE: MIT shared memory extension
> -----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