[bind10-dev] proposed design of scalable in-memory zone loading/updating

[Michal 'vorner' Vaner]

Hello

On Thu, Jun 21, 2012 at 11:57:30PM -0700, JINMEI Tatuya / 神明達哉 wrote:
> The main purpose is to allow asynchronous (background) loading and
> releasing, but the proposal introduces more generalized framework so
> it can also be used for shared-memory type architectures (like the
> case of the other proposal, at the risk of offering something
> over-engineered).

I have few comments there. I see that we'll need something like this in the end,
and I prefer doing it the final way right away than having 3 refactors on the
way, so I think it is better.

However:
• The „MemoryEventManager“ seems to suggest there's a main-loopish thing hidden
  inside and that it'll dispatch events somehow.
• I'm little bit worried about the auth pushing the updates to the in-memory
  clients. When we switch to the new data sources, the in-memory clients would
  be effectively hidden from auth and there'd be multiple ones (as caches for
  multiple data sources). I think we'll need an other way around ‒ each
  in-memory contacts the manager and asks for data for the zones which should be
  inside (and, possibly, updates).
• Would it be better to just return the continuation object after some amount of
  work, no matter if it is IXFR or AXFR (because there can be small AXFR and
  large IXFR and we will need to keep track of how much was done in the chunk
  anyway)?
• Would releasing really be time consuming? Wouldn't just dropping the memory
  segment be enough? That would be fast.

But I'm most worried about the continuation objects (which would be,
effectively, coroutines). That could get really tricky (because we'll need to
remember state somehow, etc). In short, I consider working with continuation
objects a really interesting part of programming, but it might be better to
avoid it. So I'm wondering two things:
• Would it make more sense to launch a thread? Because the thread would do no
  communication with the rest of the app, so it would be safe, we wouldn't need
  much locking (only to check if it ended already). Then we could do the loading
  in a more straight-forward sequential logic.
• Would it be more work to do the external manager process and shared memories
  than the continuations? If not, we might want to support only the external
  manager.

With regards

-- 
Please stay calm. There is no use both of us being hysterical.

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/20120622/e8558f5d/attachment-0001.bin>