[bind10-dev] easy part for handle non-empty node

JINMEI Tatuya / 神明達哉 jinmei at isc.org
Fri Jan 21 23:37:10 UTC 2011


At Fri, 21 Jan 2011 15:09:34 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> On Fri, Jan 21, 2011 at 06:16:25PM +0800, feng wrote:
> > >Hmm, it doesn't really seem right, as the same kind of tree will have
> > >the boolean variable set to the same value every time. And, as it is
> > >tree of trees, don't we need to propagate it trough all of the nested
> > >ones?
> > I am a little confused, actually, the interface should only be called once
> > for each tree, either you need expose empty node or don't need. There
> > is no this kind of requirement that sometimes you needs expose and other time 
> > do not.
> 
> Yes, that is what I mean. Yeach time the tree is instantiated for
> another data type, the bool variable will be the same for all
> instances of the class, but still checking it in the code. So the
> variable and the check is useless in the code if it will be the same
> all the time. It's not really a problem, it's just the feeling that
> it doesn't _look_ nice.

Not fully thought about it, but from what I've seen I think the best
(practice) solution is Michal's "another solution":

At Fri, 21 Jan 2011 10:32:28 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> Another suggestion: Have the bool as a parameter of the find function (either
> template or non-template with default).

This is actually what BIND 9 (essentially) does, and so it would make
most sense as what we are basically doing is a relatively
straightforward port of the BIND 9 version.

I'm not 100% sure whether the compiler optimizes the code if it's a
normal parameter, but we wouldn't have to worry about this level of
performance penalty for this code (we'd completely revisit the data
structure when we get to a full optimization phase).  Or, if it
doesn't make the code too complicated we could template this property.

Also, I don't think we have to care about the insert case.  In
practice, the only user of this tricky version of find() is the
MemoryZone class, and it needs to handle the ALREADYEXISTS case
anyway:

        switch (domains->insert(name, &node)) {
            // Just check it returns reasonable results
            case DomainTree::SUCCESS:
            case DomainTree::ALREADYEXISTS:  // <- we cannot eliminate this
                break;

because ALREADYEXISTS can happen for non empty name (when we are
adding two or more types of RRsets for the same name).  So, it won't
help anything in practice to change the insert() behavior depending
on whether or not we'd return an empty node in find().

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.



More information about the bind10-dev mailing list