On 11/04/2011 09:53 PM, Mathieu Desnoyers wrote: > * Lai Jiangshan ([email protected]) wrote: >> On 11/04/2011 06:08 PM, Mathieu Desnoyers wrote: >>> * Lai Jiangshan ([email protected]) wrote: >>>> On 11/03/2011 01:23 AM, Mathieu Desnoyers wrote: >>>>> * Lai Jiangshan ([email protected]) wrote: >>>>>> We use hash value to determine the range of the object >>>>>> and use cds_lfht_lookup_fct to lookup them. >>>>>> >>>>>> Signed-off-by: Lai Jiangshan <[email protected]> >>>>>> --- >>>>>> rculfhash.c | 8 ++++---- >>>>>> tests/test_urcu_hash.c | 25 ++++++++++++++++++++++--- >>>>>> urcu/rculfhash.h | 4 +++- >>>>>> 3 files changed, 29 insertions(+), 8 deletions(-) >>>>>> >>>>>> diff --git a/rculfhash.c b/rculfhash.c >>>>>> index d1a1766..29054cd 100644 >>>>>> --- a/rculfhash.c >>>>>> +++ b/rculfhash.c >>>>>> @@ -1391,14 +1391,14 @@ struct cds_lfht *_cds_lfht_new(cds_lfht_hash_fct >>>>>> hash_fct, >>>>>> return ht; >>>>>> } >>>>>> >>>>>> -void cds_lfht_lookup(struct cds_lfht *ht, void *key, size_t key_len, >>>>>> +void cds_lfht_lookup(struct cds_lfht *ht, unsigned long hash, >>>>>> + cds_lfht_lookup_fct match, void *arg, >>>>> >>>>> arg -> key ? >>>>> >>>>> for "match", our approach is to provide this function as parameter to >>>>> cds_lfht_new rather than pass it as parameter each time a lookup is >>>>> performed. What is the reason why we should pass it here as a parameter? >>>>> >>>> >>>> Allow the user define it. >>>> In the test, I pass match = a function always returns true when need, >>>> thus cds_lfht_lookup() returns the first node of same-hash-value-chain. >>> >>> This looks like an interesting debug and testing feature, but I don't >>> really see why we should complicate the API to include this. Is there a >>> real-life use-case you have in mind besides testing ? >>> >>> If we only need this for testing, we can use a static variable in the >>> test program to influence the behavior of cds_lfht_test_lookup. >>> >>> The other patches look fine, I'm just concerned about this one because >>> it adds complexity to the API which does not seem useful to end-users. >>> >> >> I think a generic API is OK. >> >> Sometimes the caller don't have the key or the keys which are big >> are saved separated. Example: file server >> Or key comparation is too slow. >> Or caller just need approximate lookup. >> Or caller want to compare keys with different strategies for performance. > > These arguments are appealing. However, this modification seems > incomplete: we would need to also modify cds_lfht_next_duplicate, and > *cds_lfht_add*, so they also can specify their own compare_fct strategy, > and remove the compare_fct from the lfht_new arguments, right ? >
Yes. I planned. But they don't be required for struct cds_lfht_node changes, so they can be done later. _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
