[bind10-dev] milestones for shared memory support

[Michal 'vorner' Vaner]

Hello

On Thu, Apr 25, 2013 at 12:11:42PM -0700, JINMEI Tatuya / 神明達哉 wrote:
> > 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.

I split up the ticket into three smaller ones (#2930, #2931, #2932). I believe
the first one is too simple, so it handles both python and C++ updates. I put
that one to the next-sprint-proposed and the first milestone, as that is the
part that #2922 depends on. For the feature to be of any use, we still need
#2931 to receive the notifications in python, so I put that one to the second
milestone.

I don't know if we'll need the #2932 for the shared memory work, but we should
provide it soon enough anyway, so we may start switching our notifications to
the framework (like a new zone data available, instead of hard-coding list of
modules to send a command to).

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

Right, in that case, #2923 is completely unneeded. I removed it from the meta
ticket. Could we close it as well? Or, do we want to implement it as the
cleanup, sometime during the work (it probably doesn't have to be hard
dependency for anything).

With regards

-- 
Hello, I'm an extension to the infamous signature virus, called spymail.
Could you please copy me into your signature and send back what you were
doing last night between 10pm and 3am?

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/20130426/4ced00fb/attachment.bin>