On Sat, Nov 5, 2016 at 3:47 PM <leobal...@gmail.com> wrote: > > The map is also rather big and I want to avoid creating a temporary copy > of it. > > > In Erlang, you have a call on ETS tables called ets:safe_fixtable(Table, Fix). This makes the table safe for traversal until you remove the fix again. The rule is that items inserted into the table can be hit by the traversal, but no items are removed until you release the fix (this is what makes the traversal able to actually run over the whole table).
It's internal implementation is that it keeps a "secondary" set of things while the primary is being traversed. Thus, you don't need a temporary copy as you "lock" the table while it is being traversed and add other stuff into a table next to it. Once you want to release the lock, you replay the changes on top of the table. The gist is you don't need a deep copy and if there are relatively few changes to the table, this is way faster in replay. In fact, in the Erlang implementation, it is enough to track deletions. If we update a satellite value for a key, we can still (safely) traverse the table since the key is still present. The problem is when we remove a key in which case the traversal could have a "hole" which makes us miss the next hash bucket. While we are doing this, we can go to the deletion set before going into the hash table and if there is a "tombstone" present in the deletion set, we regard that value as deleted. I wonder if some of these ideas can be salvaged into a solution in your case? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
