This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: key64_t? ino64_t?


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.
>
>ACK.
>
>> 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)
>> http://www.cygwin.com/ml/cygwin-xfree/2002-05/msg00155.html
>> "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
name.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]