BIND 10 #327: early work on recursion
BIND 10 Development
do-not-reply at isc.org
Fri Nov 12 02:00:46 UTC 2010
#327: early work on recursion
---------------------------+------------------------------------------------
Reporter: each | Owner: each
Type: defect | Status: reviewing
Priority: major | Milestone: y2 12 month milestone
Component: recurser | Resolution:
Keywords: | Sensitive: 0
Estimatedhours: 0.0 | Hours: 0
Billable: 1 | Totalhours: 0
Internal: 0 |
---------------------------+------------------------------------------------
Comment(by jinmei):
Replying to [comment:17 each]:
> Regarding the asio::io_service interface, I think that came out of the
original asio_link_unittest.cc from trunk. I had assumed this was by
design--the IOService class included a get_io_service() member to give
access to the underlying implementation.
>
No, it's not by design but a short term workaround. In fact, it's clearly
documented at least in the latest trunk version:
{{{
/// \brief Return the native \c io_service object used in this
wrapper.
///
/// This is a short term work around to support other BIND 10 modules
/// that share the same \c io_service with the authoritative server.
/// It will eventually be removed once the wrapper interface is
/// generalized.
asio::io_service& get_io_service() { return
io_service_.get_io_service(); };
}}}
The only reason we needed get_io_service() is the cc session module still
required the row asio::io_service.
For that matter, I also don't think it's by design that the naming of this
function doesn't follow our guideline (it would have been getIOService or
getASIOIOService or something). I noticed that when Jelte first
introduced it, but since the idea was to obsolete it soon anyway I didn't
touch that.
--
Ticket URL: <http://bind10.isc.org/ticket/327#comment:18>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list