[bind10-dev] Multicore Auth

[Shane Kerr]

Michal,

Thanks for rebooting this discussion.

On Tue, 2011-07-12 at 23:52 +0200, Michal 'vorner' Vaner wrote:

> For the record, I myself probably would put this order of preference to them
> (the one I like most first):
> • Shared memory
> • Fork
> • Threads
> • Multiple processes

There is an additional drawback to threads and shared memory, which is
fate-sharing.

If there is some programming bug that gets detected, then there is a
good chance we'll need to terminate. Even worse, if memory gets
corrupted, then all concurrent bits of processing will be affected. This
is especially true in the threading case, where the shared memory is
implicit. For explicit shared memory we can possibly reinitialize the
shared memory segment and proceed with only a minimum of user-affecting
pain.

There are still cases where fork or multiple processes will have fate
sharing... like if an update to an in-memory data source causes failure,
then it can easily cause failure to all copies at the same time.

Looking at it from  this point of view, "multiple processes" provides
the most protection. However, using a read-only shared memory probably
provides basically the same amount.

So, I think I am inclined to agree that a shared memory model for
in-memory data sources is the way to go (or mmap or the like). I also
like Stephens suggestion of working on a copy and then signaling that
this is the one to use, plus the variant of releasing the old copy when
all read-only processes have switched away from it.

--
Shane