RE: TnyAccountTreeModel is now a TnyListIface

[Philip Van Hoof <spam pvanhoof be>]

On Wed, 2006-07-05 at 17:56 +0200, Philip Van Hoof wrote:

> If you have your TnyIteratorIface in the heap, like in your sample, it
> wouldn't be possible to make your sample thread-safe, unless it's a new
> allocation (thus a new object each time you'll iterate). But that means
> that you need to destroy it.

Allow me to clarify this. Say you have 65,000 threads all iterating the
same list simultaneously. If you would now return the same instance to
the iterator, the threads would mixup the iterator itself. So each
thread needs his own iterator instance.

That is also what you'll see in the implementation: each iterator has a
"current" pointer. The "first" pointer of the list implementation, never
ever changes (unless something is added, and in that case, iterator_lock
is being locked).

The iterator_lock will when this "first" pointer changes, lock all
iterators. So say a threads at the same time wants to iterate to the
next item, it'll have to wait for the append, prepend or remove event to
be fully completed. That way will "first" always point to the right
"first" item of the list. And that way will "current->next", in the
iterator instance, always go to the right new item.

> The iterator in GtkTreeView/GtkTreeModel, GtkTreeIter is typically
> allocated on the stack and for each iteration you are going to perform.
> It will therefore get destroyed automatically when the stack frame ends.
> I'm guessing the same thing happens with the C++ iterators and/or maybe
> in C++ smartpointers are used for the iterator destruction.


So basically ... each time you iterate a list, you create a new
iterator. This iterator is not going to change the list. It will keep
the current item itself. If something changes to the list, none of the
iterators is still guaranteed to be valid (and this is documented to be
the case).


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be