[bind10-dev] milestones for shared memory support

[JINMEI Tatuya / 神明達哉]

At Thu, 25 Apr 2013 13:53:32 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > Then how would memmgr get changes of subscribers of the
> > "MemorySegmentReaders" group? (the group name is tentative, referring
> > to http://bind10.isc.org/wiki/SharedMemoryIPC)
> > 
> > Do you mean memmgr would subscribe to a "special"
> > "FollowersOfMemorySegmentReaders" group?  But then how can msgq know
> > this "followers" group is about the interest in the
> > "MemorySegmentReaders" group?  I thought group names are opaque to
> > msgq, just some unique names for sets of session IDs.
> 
> Well, two points here. One is, I actually expected to have just one special
> group for all the groups, like „Notifications/Msgq/Groups“, which would include
> notifications about subscriptions to all the groups. [...]

I don't know if this is the cleanest approach, but I'm okay with any
workable one.  So I don't object.

> > > and we are missing a dependency here. We don't support notifications, there will
> > > be some work to allow them. We'll have to create a function to create a
> > > notification (as we have createCommand and createAnswer, so we would have
> > > createNotification). Receiving end will be little more work, because we need to
> > > register callbacks.
> > 
> > If you think we need another ticket or include some existing one to
> > the list for the milestones, please do so.
> 
> Well, feature-wise, we need #1915 for this to work. I don't know if we want to
> split it up into some sub-tickets, since this is probably more like a low-level
> feature ticket than task ticket.
> 
> Is there a live list of the tickets/milestones, or is the only instance your
> email?

#2830 is a meta ticket listing all relevant task tickets.  I've
updated it with a summarized version of milestones.  I'm not sure how
large #1915 is expected to be, but for the purpose of the shmem
feature we'll only need a Python version of API to get changes to
group subscribers (I'm assuming we'll write memmgr in Python).  So
ideally we define a minimum set of tasks (hopefully only one more) to
realize this goal.

> > > We may want to have some kind of rpcCallMulti.
> > 
> > I'm not sure what this one is supposed to do.  Send the same command
> > to multiple session IDs (as separate messages)?  If so, I suspect
> > we'll face the same problem as the semantics of "answer from a group",
> > i.e., what if a subset of the answers indicate a success and rest
> > indicate failure, etc.  I thought the semantics can be only determined
> > by the application (user), not at the API level.
> 
> It would be supposed to send the command to multiple recipients, yes. But I
> thought of just returning all the answers in some way. If we wanted a blocking
> mode, it would be something like returning vector<pair<bool, ConstElementPtr> >.
> Or, the non-blocking could be something like:
> 
> AsyncID rpcCallMulti(…, successCallback, failureCallback, completionCallback).
> 
> The successCallback would be called for each successful answer, failureCallback
> for each failure and completeionCallback after all the answers (positive or
> negative) were received, to indicate there'll be no more.
> 
> It is complex API, but it still hides the details of asking Msgq the list of
> lnames and sending to each of them, etc.

First, like the case of notification discussed above, we'll only need
a Python API for the purpose of shmem feature.  And, memmgr itself
will need to manage a list of subscribers explicitly (and I assume
this information will be given in the form of lnames so the
user=memmgr can use them to specify the per-session-ID destination
opaquely), so the part of skipping to ask msgq won't be much useful in
this case.  I'm not necessarily opposed to introducing a wrapper API
for sending the same message to multiple session IDs, but in the
context of the shmem feature work my impression is that we'd rather
use the primitive API (thus saving time to develop the advanced API)
and have memmgr call it for each subscriber.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.