[bind10-dev] Thinking aloud: Multi-CPU auth

[Stephen Morris]

On 18 Dec 2010, at 10:26, Michal 'vorner' Vaner wrote:

> All three of them have slight problems with updating data. If we have some kind
> of SQLish data source, then it will probably take care of the updates, locking
> and stuff all by itself. But with the in-memory one, everyone has its own copy.
> So we either need to signal everyone else, or have it somehow shared. And I'm
> not sure we can have a shared lock on shared memory (because we want concurrent
> reads as much as possible). Another way would be that, in case of forking, the
> parent would do the updates and then restart the children (if there were many
> changes, it would have to be limited in some way, for example no more often than
> once every 5 minutes).
> 
> Do the ideas make some sense? Improvements and simplifications welcome ;-).

Shared memory does seem the best way forward.

If we were to put the in-memory data source into a shared memory segment, could we not have the updater process map it and copy it into a new shared memory segment, modify the latter, then signal the processes to suspend queries, unmap the old segment, map the new one and restart query processing?  That way no locks are needed.

The one concern I do have about the shared memory is that we are implementing an in-memory data source using C++ objects.  We would need to do our own memory management and use our own allocators etc. to ensure that all the objects are in shared memory.  This could get tricky for things like strings that are used in both shared and non-shared contexts.

Stephen