pika-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pika-dev] Re: Hashtrees a bit unflexible


From: Tom Lord
Subject: [Pika-dev] Re: Hashtrees a bit unflexible
Date: Wed, 17 Mar 2004 08:49:53 -0800 (PST)

    > From: Andreas Rottmann <address@hidden>

    > Tom Lord <address@hidden> writes:
    > >     > From: Andreas Rottmann <address@hidden>
    > >     > I just noted that hackerlabs hashtrees are a bit unflexible 
compared
    > >     > to the GLib ones: You cannot pass an additional pointer to e.g. 
the
    > >     > hashtree_free_data_fn. I would however need this functionality to 
be
    > >     > able to keep the storage in a memchunk for efficient (esp. 
space-wise)
    > >     > allocation. 

    > >     > A hack to do so would involve using a special "rules" structure 
that
    > >     > has an additional field. Is this the way it's ment to work, or 
should
    > >     > hashtree functions be extended to take an additional void * 
argument?
    > >     > If the argument would be last, this change wouldn't break ABI wrt
    > >     > existing usage, I think. Tom?

    > > Data and keys should be coextensive with `struct hashtree' nodes.
    > > Thus, the `free_hashtree_fn' should be able to do what you want.   Is
    > > there some reason why it can't?

    > The thing is, the data lives in a "memchunk". To free it, I need not
    > only the pointer to the data (item->binding, no problem so far), but
    > also a pointer to the memory chunk, so I need to funnel that somehow
    > into hashtree_free_data_fn. As noted in my other mail, this can be
    > worked around using the newly created hashtree_fold() function, but
    > this is somewhat suboptimal from a perfomance POV.

The memchunk is constant throughout the tree, right?   In other words,
all of the keys and values in a given table use the same memchunk?

I would usually solve that by using a different `struct
hashtree_rules' for each memchunk.   Something like:


        struct my_hashtree_rules
        {
          struct hashtree_rules rules;

          t_memchunk chunk;
        };


In the free_fn, you'll get the address of the `rules' field of one of
these --- and you can cast that back to being the address of a `struct
my_hashtree_rules'.

Hashtree is _lower_level_ than the glib hash tables -- but that's on
purpose.  It's intended to be suitable (flexible) for implementing
more specialized tables with higher level intefaces although, yes, it
does wind up often being used directly.

-t






reply via email to

[Prev in Thread] Current Thread [Next in Thread]