[bind10-dev] Simplification of the memory manager

[Shane Kerr]

Michal,

On 2013-08-22 10:27:42 (Thursday)
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> Threads
> =======

> So I propose we still have two threads, but one of them would only
> read things from the msgq socket and queue them for the other. The
> other would do all the rest of work (eg. the communication would be
> one way only and there would be no sending of state updates back and
> forth).

This seems reasonable to me, and in fact is quite a logical split of
work IMHO.

> One state for all the data sources
> ==================================
 
> Let's synchronize the state too and have only one copy of the state
> and the readers. We do some updates (potentially on all of them) and
> then send updates on all the changed ones. After all the updates are
> applied, start with more updates. Effectively, change the whole
> complex ping-pong logic into this:

Seems cleaner as well. I don't actually see much performance drawback
to this change, if any.
 
> The updates should be synchronous
> =================================
 
> Let's not store the set of clients we expect ACK for through the
> application. Let's do the communication in a code-local fashion. Just
> broadcast the updates and wait for all the answers. Don't do anything
> else until there are back. This should be fast, as the readers need
> only map the segment.

This makes sense, since the only real activity for the readers that may
take any significant time is accessing the data sources. If someone
mixes a very slow data source with this then it could slow things down
a bit, but that's a simple case of "don't do that". :)
 
> Do the updates as single command
> ================================

> This would require small update to the auth code too, because
> currently auth does useless thread exercise there. It takes the
> update that takes no time and queues it for the work thread and waits
> for the work thread to return notification it was done. Why so
> complicated? Let's just lock, mmap, send answer and be done.

Also makes sense, with the same observation as above.
 
> Have just one history snapshot
> ==============================

> Let's keep just the current one. We are not capable to keep track of
> more across history and I don't see the reason to do that.

Hm... I'm not sure why we had a long history, so it is hard to say
whether we need it. :-P  Any ideas?

> I'm going to suspend work on #2858 for now, until we decide what we
> do with it. Also, #2857 may be put aside, as it would be one of the
> things that would not be needed (or, most of it at least).

Okay I'd like to talk about this on our call later today.

Cheers,

--
Shane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130827/2b185f0c/attachment.bin>