key64_t? ino64_t?
Charles Wilson
cygwin@cwilson.fastmail.fm
Wed May 14 06:36:00 GMT 2003
On 11 May 2003 14:07:14 +1000, "Robert Collins" <rbcollins@cygwin.com>
said:
> 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.
>
> (*) st_dev may not be needed in the key once we are using the native
> inode values - IF the NT upper 64 bits are the filesystem ID. IF they
> are, then we have the native device id already in the key so our key
> becomes
>
> struct {
> native_inode_t inode;
> u_short keyid;
> };
Unfortunately, the NT upper bits are not the filesystem ID, according to
Corinna's investigation. So, we need dev_t, too. And besides, the
struct idea is a really really bad, IMO. People expect key_t to be a
primitive, don't they? Sure, key1 < key2 doesn't mean anything, but key1
== key2 ought to be meaningful. So, you'd have to implement operator==,
which makes key_t a class, not a struct.
But that kills packing (e.g. a key_t object is no longer '72 bits of id
data') because key_t now has vtables, ctor, dtor, etc etc. I *really*
don't like the idea of making key_t a non-primitive type. Why should we
-- linux doesn't, and they've decided to live with aliasing into 32bits.
Surely we can live with a 64bit space, and its one billion times lower
probability of clashing?
What do you think of the attached patch? (The comments explain my
rationale).
--Chuck
--
Charles Wilson
cygwin at removespam cwilson dot fastmail dot fm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 64bit_keyt.chg
Type: application/unknown
Size: 316 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20030514/c16bfdec/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 64bit_keyt.patch
Type: application/unknown
Size: 7122 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20030514/c16bfdec/attachment-0001.bin>
More information about the Cygwin-developers
mailing list