Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3EBD3896.8000202@ece.gatech.edu>
Date: Sat, 10 May 2003 13:36:22 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: cygipc (and PostgreSQL) XP problem resolved!
References: <20030507133326 DOT GA1824 AT tishler DOT net> <3EB9A54B DOT 8060500 AT ece DOT gatech DOT edu> <20030508135217 DOT GD512 AT tishler DOT net> <3EBB22F5 DOT 4000801 AT ece DOT gatech DOT edu> <1052541657 DOT 1675 DOT 5 DOT camel AT localhost> <3EBC8ED0 DOT 4040906 AT ece DOT gatech DOT edu> <20030510072239 DOT GA19367 AT cygbert DOT vinschen DOT de> <1052554219 DOT 1824 DOT 14 DOT camel AT localhost> <20030510082949 DOT GD19367 AT cygbert DOT vinschen DOT de> <3EBD3179 DOT 6070004 AT ece DOT gatech DOT edu> <20030510171629 DOT GB11448 AT redhat DOT com>
In-Reply-To: <20030510171629.GB11448@redhat.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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/