Threadsafe project model

[Andreas Pakulat]

On 16.07.10 09:34:36, Esben Mose Hansen wrote:
> On Friday 16 July 2010 01:52:03 Andreas Pakulat wrote:
> > Then the model would still be thread-unsafe and can be declared as such
> > and still be somewhat usable from a background thread (as far as
> > notifying the gui of changes is concerned).
> 
> How about simply queueing the additions? Do the background thread really need 
> the added items to work? Then the GUI thread could pick up the additions when 
> it got around to it,  the model signals wouldn't give us problems, and the 
> background parser wouldn't be blocked by the GUI thread.
> 
> the signature could be something like 
> 
> void add_new_item(id, parent_id, data1,, data2, data3);
> 
> where the id is a suitable id that can be calculated from the background 
> threads. If all else fails, you could always use thread-id + running number, 
> or even a unique id.

Its not that easy. The parsing of the project is done in multiple
threads (currently) and one step has to produce a list of items that are
then used for the next iteration (if they're folder items). So the items
need to exist as soon as the parse() method returns. 

However as the items themselves don't have any thread-affinity as
they're not QObjects and we can easily make sure the signals for model
API are sent out asynchronously if necessary I don't think this is
needed anyway.

Yes the model is not threadsafe, but except for the creation of items in
the background thread this was not a problem so far and by stating
clearly that the model is not threadsafe it shouldn't get a problem in
the future either as any code trying to use it from any thread but the
GUI thread is broken by definition.

Much more problematic is that all kind of places hold onto pointers to
items, which can indeed be deleted any time and hence cause dangling
pointers.

Andreas

-- 
Good night to spend with family, but avoid arguments with your mate's
new lover.