This is the mail archive of the 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: cygipc (and PostgreSQL) XP problem resolved!

On Sat, May 10, 2003 at 01:36:22PM -0400, Charles Wilson wrote:
>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...

Where applicable, cygwin is going to use Microsoft's notion of an
"inode" without resorting to the crude "hashing" that Cygwin now does.
win32 uses two 32 bit quantities to account for the "file index" on
disk.  I assume that, in most cases, the high order byte is probably
zero but I don't know for sure.


Unsubscribe info:
Problem reports:

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