BIND 10 #2856: memory manager initialization

[BIND 10 Development]

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

 * owner:  muks => vorner


Comment:

 Replying to [comment:15 vorner]:
 > > > 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?

 Right now memmgr does not call any of these methods (in `SegmentInfo`)
 at all. But I don't follow this anymore. What behavior changes are
 suggested 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.

 #3079 (Don't build and install memmgr where shared memory support is not
 available) was created for this.

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