BIND 10 #2856: memory manager initialization

[BIND 10 Development]

#2856: memory manager initialization
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:  muks
                Type:  task          |                       Status:
            Priority:  medium        |  reviewing
           Component:  shmem         |                    Milestone:
  manager                            |  Sprint-20130806
            Keywords:                |                   Resolution:
           Sensitive:  0             |                 CVSS Scoring:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  4             |  Feature Depending on Ticket:
         Total Hours:  0             |  shared memory data source
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => muks


Comment:

 Hello

 Replying to [comment:14 muks]:
 > > I know it is described in the ticket this way, though.
 >
 > I guess we'll know better how to handle this once we start using these
 > methods in memmgr.

 Yes, I don't know if it's so cool to do the bottom-up development, since
 we build classes we don't see the exact reason for yet :-|.

 > > I think we should allow it.
 >
 > Reading this again, I wonder if memmgr is supposed to populate and
 > maintain readers (from the group) only after `start_update()` is issued?
 > And then it stops maintaining this list after it gets back to `READY`
 > state. Otherwise I don't follow why it is designed this way.

 Same as with unsubscriptions, subscriptions can come at any time IMO.

 But it probably depends on the current state it is in, to which set to put
 them and so.

 What is done now?

 > I agree memmgr doesn't make any sense without shared memory, and we can
 > install it conditionally. Given the other memmgr tickets, would auth,
 > etc. work properly without memmgr running? We should keep this in mind
 > as we complete the shared memory work.

 As far as I follow the development, I think auth should work well enough
 without memmgr, provided it doesn't use the mapped segments. If it tried
 to use the segments, it would not get them, so the zones would stay
 unavailable and it would return something like SERVFAIL for the queries to
 them, but the rest of zones would work OK.

 > Shall I make another ticket for it, that conditionally installs memmgr?

 It might make some sense, so yes, please.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2856#comment:15>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development