Stephen Gallagher wrote:
On 09/13/2010 08:13 AM, Stephen Gallagher wrote:
> The idea behind the hash is actually to have it double as a reference
> count and a loop-detection mechanism. It doesn't need to be a hash (it
> could just as easily be a b-tree), but since we already have an
> efficient hash available, I was just going to use that.
> The idea is that for every time we recurse down a level, we will add the
> name of that netgroup to the hash. Before recursing down again, we'll
> make sure that the new name is not a key in the hash. If it is, we know
> we've hit a loop and should break processing.
> When we recurse up a level, we need to remove this entry from the
> tracking hash so that it's possible to recurse down into it again in a
> different branch of the tree. There is a pro and con to this approach.
I forgot to mention that the other use of the hash is that it provides
an easy way to handle nesting limits. A dhash table provides an
interface for requesting the number of entries in the hash. If one more
subrequest is going to exceed the maximum nesting level, then we can
cancel the request.
So using a tracking dhash here just makes the nesting limit and
loop-detection very easy.
Yes. I agree with this. Hash is definitely the best object for the task.
It is just that algorithm has a flaw I pointed in the other mail.
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
--
Thank you,
Dmitri Pal
Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/