[Top][All Lists]
[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