BIND 10 #2836: update in-memory zone loading so it can work with shmem segment
BIND 10 Development
do-not-reply at isc.org
Wed May 15 11:38:18 UTC 2013
#2836: update in-memory zone loading so it can work with shmem segment
-------------------------------------+-------------------------------------
Reporter: jinmei | Owner:
Type: task | jinmei
Priority: medium | Status:
Component: data source | reviewing
Keywords: | Milestone:
Sensitive: 0 | Sprint-20130528
Sub-Project: DNS | Resolution:
Estimated Difficulty: 4 | CVSS Scoring:
Total Hours: 0 | Defect Severity: N/A
| Feature Depending on Ticket:
| shared memory data source
| Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
Changes (by vorner):
* owner: vorner => jinmei
Comment:
Hello
Replying to [comment:18 jinmei]:
> Part of #2850 has been merged to master. I believe all that this
> branch needs are now there, and won't require future changes due to
> the rest of #2850 discussions. That is, you should now be able to
> merge/incorporate it for this branch safely.
I did a merge with master as the first commit today. It's large and with
some conflicts, but it contains mostly just updates to the change of
interface.
> Ah, okay. Actually scoped pointer is even non copyable. So it can't
> be used as a return value of a function. In this test usage, however,
> `SegmentCreator::create()` seems to be able to just return the result
> of `new` and have the caller store it in a scoped_ptr. But that's not
> a big deal and mostly a matter of taste.
I just feel calmer when I don't see raw pointers being returned, as it is
not always clear who should delete it if anybody.
> > I also pushed the test that crashes for me. Does it crash for you too?
Does valgrind work for you? If so, could you run it through it?
>
> That test crashed in my environment, too (though in a different place
> of the code). I've found one issue and committed a fix to that (my)
> problem at 575854a507052ad7de51aa259fd5d8f04156d15d on branch
> trac2836-2. Hopefully it will fix yours, too. Note that we may or
> may not use the 5758... fix as it is (see below).
I incorporated changes inspired by yours, and the separate set as well.
The test now passes, so I hope it works as it should. But I'm still not
100% sure there's no other bug like this.
> An incomplete insert() (due to exception in the middle of it) could
> cause a new empty node as a result of `nodeFission()`, which will
> now be found by find() if the domain tree was constructed
> accordingly. I suggest combining and updating several related
> paragraphs as follows:
ACK.
> - maybe we'd note getNextHolderName() is not thread safe (but should
> be okay as a memory segment isn't expected to be modified by multiple
> threads at the same time in the first place)
Actually, it's little bit worse, because the constructor of the holder is
not reentrant this way. I don't know if it is a problem. If it is, we may
want to either think of better way or create some kind of locking.
> - depending on how we revise `SegmentObjectHolder`, `result.zone_data`
> could also be relocated on return of `addZone`.
I don't see how that could happen or how to protect against that. Can you
explain where it would relocate?
> '''zone_finder_unittest.cc'''
> - what's the purpose of changing `updater_` to (scoped) pointer?
So I can release it during a test. As a result of the data being stored in
the updater for whole lifetime, it is not possible to have two updaters at
once and there's actually a check for it. And some tests load a zone from
file or somewhere, which creates its own updater. So I need to remove the
one created by the test fixture.
IMO this should be all the functionality for the branch. Or I hope so.
Many thanks for pointing me to the problem of the test.
--
Ticket URL: <http://bind10.isc.org/ticket/2836#comment:20>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list