BIND 10 #2265: cleanup: remove Renderer::clear() calls
BIND 10 Development
do-not-reply at isc.org
Tue Sep 18 16:49:52 UTC 2012
#2265: cleanup: remove Renderer::clear() calls
-------------------------------------+-------------------------------------
Reporter: jelte | Owner:
Type: task | Status: new
Priority: | Milestone: Next-Sprint-
medium | Proposed
Component: | Resolution:
Unclassified | Sensitive: 0
Keywords: | Sub-Project: DNS
Defect Severity: N/A | Estimated Difficulty: 5
Feature Depending on Ticket: | Total Hours: 0
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Comment (by jinmei):
Replying to [comment:2 jelte]:
> nono, no change to toWire() calls, only calls to clear().
Ah, I actually meant `clear()` but mistyped it as `toWire()`.
> in #1357, we found a problem: if clear() is not called before every
single call to toWire(), bad things happen. So I porposed to actually do
clear() in Message::toWire() itself. And if that get's through, we
suddenly have a lot of unnecessary calls to clear() (everywhere, but in
theory easily greppable).
Ah, okay. That may make sense in some sense. On the other hand, I
guess we should still encourage the application to clear the renderer
once it's done with it. That's partly because the renderer could hold
a relatively large amount of temporary resource and until the next
call to `Message::toWire()`, which is generally unpredictable. It
could be more serious if and when we introduce an optimized renderer
implementation for the in-memory data source that internally maintains
some reference to the data source related objects that may be
invalidated after the query processing.
But then if the application follows the cleanup convention, the call
to clear() within `Message::toWire()` will be redundant, and it will
possibly be a non-negligible overhead for performance sensitive
applications like b10-auth.
So I think we need some better middleground. Based on this discussion
with my older suggestion, I think we could do:
- have `Message` objects maintain their own renderer and provide a
read-only accessor to it.
- introduce another version of `Message::toWire()`. It doesn't take a
renderer, but dumps the wire-format data to the internally
maintained renderer. the application can then retrieve the data via
the accessor method (we can make the python version more convenient
as I suggested in my previous comment)
Normal (non performance sensitive) applications will use the latter
version. Then these apps don't have to create/maintain a renderer
themselves. Only performance sensitive apps will use the interface
that takes an external renderer. Such apps are responsible for
clearing the renderer after they are done with it.
--
Ticket URL: <http://bind10.isc.org/ticket/2265#comment:3>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list