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