BIND 10 #2850: Define and implement ZoneTableSegmentMapped
BIND 10 Development
do-not-reply at isc.org
Mon May 13 16:18:26 UTC 2013
#2850: Define and implement ZoneTableSegmentMapped
-------------------------------------+-------------------------------------
Reporter: jinmei | Owner:
Type: task | jinmei
Priority: medium | Status:
Component: data source | reviewing
Keywords: | Milestone:
Sensitive: 0 | Sprint-20130514
Sub-Project: DNS | Resolution:
Estimated Difficulty: 5 | CVSS Scoring:
Total Hours: 0 | Defect Severity: N/A
| Feature Depending on Ticket:
| shared memory data source
| Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
Comment (by jinmei):
Replying to [comment:21 muks]:
> > one more note: I've noticed another issue with
> > `MemorySegmentMapped::setNamedAddress(Impl)`. If the underlying
> > segment grows inside this method, the given pointer can be invalidated
> > by the time the storage is allocated.
>
> Isn't this the same reason why we allocate the name with `NULL` address
first, and repeat it with the real address after allocation? Or is it some
other issue?
It's essentially the same problem, but at that time we (or at least I)
mainly were concerned that we might have to re-get the address as the
mapped address may change before and after the call to
`setNamedAddress`. The above issue is more about `setNamedAddress`
internal. For example, even if the caller simply calls
`setNamedAddress` and then closes the segment, it's still problematic,
because `addr` may be invalidated if `find_or_construct()` requires
retry:
{{{#!cpp
offset_ptr<void>* storage =
impl_->base_sgmt_->find_or_construct<offset_ptr<void> >(
name, std::nothrow)();
if (storage) {
*storage = addr;
return (grown);
}
}}}
--
Ticket URL: <http://bind10.isc.org/ticket/2850#comment:23>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list