BIND 10 #2202: introduce a lock for the data source client in auth
BIND 10 Development
do-not-reply at isc.org
Fri Sep 7 08:02:11 UTC 2012
#2202: introduce a lock for the data source client in auth
-------------------------------------+-------------------------------------
Reporter: | Owner: UnAssigned
jinmei | Status: reviewing
Type: task | Milestone:
Priority: low | Sprint-20120918
Component: | Resolution:
b10-auth | Sensitive: 0
Keywords: | Sub-Project: DNS
Defect Severity: N/A | Estimated Difficulty: 5
Feature Depending on Ticket: | Total Hours: 0
background zone loading |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Comment (by vorner):
Hello
Just a quick reply without code update (I'm going away for vacation too).
Replying to [comment:9 jinmei]:
> - Do we really need the recursive mode, at least right now?
> - s/locket/locker/?
> {{{#!cpp
> /// To lock a mutex, create a locket. It'll get unlocked when the
locker
> /// is destroyed.
> }}}
I don't know. Probably not now, but we may need it soon or later. And as
the
extra work is really small (just a condition in the constructor changing
the
attributes), I thought I just add it for completeness, so the interface
won't
need an update soon.
> - I personally would like to avoid throwing from destructors. While
> the end result may be the same in practice, I'd explicitly assert()
> it and let the process die, and keep the assumption on
> exception-freeness throughout the code.
I have no big preference. The performance-aimed build might have turned
off
both kinds of checks. I went with exceptions simply for easier testing and
nicer error messages. Do you think it should be switched to asserts?
--
Ticket URL: <http://bind10.isc.org/ticket/2202#comment:10>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list