key64_t? ino64_t?

Christopher Faylor
Sun May 11 17:47:00 GMT 2003

On Sun, May 11, 2003 at 02:07:14PM +1000, Robert Collins wrote:
>On Sun, 2003-05-11 at 13:50, Charles Wilson wrote:
>> Actaully, I don't think anything in winsup (other than cygserver itself)
>> uses key_t -- and cygserver was designed to use 64bit key_t from the
>> beginning.  So as long as the redefinition of key_t in newlib is guarded
>> by #if __CYGWIN__ (so that ./newlib/libc/sys/linux/ stuff that DOES use
>> key_t is protected from this change), I think you're home free.
>> Even though we don't want to export the cygserver stuff, we *might* want
>> to export *just* ftok.  Currently, cygipc provides it's own
>> implementation (which I hope will remain sync'ed with the cygserver
>> version after key_t goes to 64bits, IF it goes to 64bits).  That
>> synchronization is obviously much easier if there's only one copy, and
>> cygipc-the-64bit-generation uses the one from cygwin1.dll... See patch,
>> below.
>I like that idea.
>> BTW, Robert wrote in this message (concerning key_t)
>> "hashs collide. key_t's can not collide under any circumstance, and must
>> be deterministic (i.e. not dependent on currently issued keys)."
>Yah. And chris's work to use the native NT inode information will remove
>the chance of hash collisions completely. We will need with a 72 bit
>key_t, or a lookaside table. FWIW I think a lookaside table may not be
>worth the work (*). (I've changed my mind :})
>Note: You'll need cygserver running if you use a lookaside table. It
>won't be doing any ipc logic, just maintaining the persistent
>key<->inode translation.

If we're using cygserver, then global (or even local) atoms should still
be fine, shouldn't they?  We just need a unique hash value based on path


More information about the Cygwin-developers mailing list