[bind10-dev] milestones for shared memory support

[Michal 'vorner' Vaner]

Hello

On Wed, Apr 24, 2013 at 11:16:33AM -0700, JINMEI Tatuya / 神明達哉 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. There will be only small
amount of subscriptions being made (usually at startup and shutdown of modules),
so the overhead of throwing the ones that are not interesting out would be
small.

But if we wanted to have them separated, we could use something like the special
group name (I thought of something like
„Notifications/Msgq/Groups/<Group name>“). This is not completely opaque, but
the only operation that is being done is concatenating of strings, so it is
still independent of which groups are present in the system. Also, there are two
levels of msgq. One that routes the messages. The other level has commands and
configuration, and so on. I think the routing one should not interpret anything
about the groups, but the management one might.

> > 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?

> > This is actually a null ticket. If the get_sessions is command like the others,
> > we can already call it (let's say by rpcCall).
> 
> Okay, but looking at the interface again, I think the current
> rpc_call() would look a bit awkward because it takes a parameter of
> "group"; when we send a message to a particular session ID, I guess
> we'd rather not to bother specifying the group name.  So, maybe we can
> rename the current rpc_call to, e.g., rpc_call_group, and revise the
> interface of rpc_call as follows:
> 
>     def rpc_call(self, command, to, params=None):
>         """
>         to: the recipient session ID
>         ...
>         """
> (this version also removes the "instance" parameter, as it's actually
> not used for any purpose today)

I agree it might be nice cleanup of the interface. But from the dependency point
of view, it is not really necessary for completion of the shared memory work. In
that sense, I don't think it needs to be in the list.

> > All the groupSendMsg and friends support sending based on lname instead of group
> > name.
> > 
> > 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.

With regards

-- 
ASHes to ASHes, DOS to DOS.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130425/722cdd59/attachment.bin>