Re: cygipc (and PostgreSQL) XP problem resolved!

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Christopher Faylor wrote:

> > key = ((st.st_ino & 0xffff) | ((st.st_dev & 0xff) << 16)
> >        | ((id & 0xff) << 24));
> >
> > Given the sizes of the various fields of st, there are obvious problems 
> > with aliasing here.
>
>
> But, be advised that I'm in the process of changing the inode field to
> a long long so I'm not sure that we wouldn't be just pushing this off
> a little further.

Urk.  That's right -- but unless there is another primitive type that is 
bigger than 64 bits, then we're out of luck, and will have to accept 
aliasing of some sort.

st_dev = 16 bits
st_ino = 64 bits (tentative)
id     = 8 bits

To pack that into 64 bits, we need to hash st_ino down from 64 to 40 
bits.  Given your future implementation of st_inode, what distribution 
of values do you expect in the 64bits?  This will help to design the 
proper hash to minimize conflicts...

Or, we could play some truly evil games, like:

typedef union {
  long long  value; // only 64 bits long
  byte[12]   bytes; // 96 bits of storage
} key_t

and then a bunch of accessor macros, and code changes, blah blah.  Ugly. 
 I prefer to hope that the new 64bit inode is sparse, and easily hashed 
(fairly unambigiously under expected distribution patterns) down to 40 bits.

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/