BIND 10 #2281: use new in-memory data source in the static data source

[BIND 10 Development]

#2281: use new in-memory data source in the static data source
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:  muks
                Type:  task          |                       Status:
            Priority:  high          |  reviewing
           Component:  data source   |                    Milestone:
            Keywords:                |  Sprint-20130219
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DNS           |                 CVSS Scoring:
Estimated Difficulty:  4             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => muks


Comment:

 Hello

 Replying to [comment:14 muks]:
 > > If you don't link the in-memory library, how does the code get in? Is
 > > it some magic I didn't notice, or is it by accident already there? Or,
 > > who does link to the in-memory?
 >
 > I'm not sure too. Unless `-rdynamic` is specified when linking the main
 > executable, its symbols are not exposed to the module. But what seems to
 > be happening is that its symbols are indeed being exposed and linked at
 > dlopen time.
 >
 > [...]
 >
 > I don't know how it's finding its symbols.

 I wonder, is it possible the in-memory is directly linked into the data
 source library itself? Then the symbols would be available.

 I just fear if it can happen the data source can't be loaded because the
 in-memory is not available under some circumstances.

 > Now I'm not sure if my change is correct. The old in-memory data source
 > _module_ has been removed, so I thought that asking the factory to
 > return the 'memory' source would be wrong.

 That seems like a reason. Can you add a note to the test saying it uses
 the static data source as an abuse, because in-memory doesn't exist and
 that the static contains the in-memory one?

 > From what I observed, only 1 or 2 zones at most are added into the map
 > by any unittest. So any overhead is at best constant. Due to the number
 > of zones, and the data being used, it does pick the correct zone to
 > return.  I didn't want to spend more time optimizing it.

 Thanks. I wasn't worried about the performance that much (again, these are
 tests, who cares). But it could be very surprising if someone added
 another test where it returned the wrong partial match. It could take long
 time to discover that. But this version looks good.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2281#comment:15>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development