Threadsafe project model

[Andreas Pakulat]

On 16.07.10 13:18:02, Esben Mose Hansen wrote:
> On Friday 16 July 2010 11:45:58 Andreas Pakulat wrote:
> > 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. 
> 
> Then I'd have a shared list of the items created. In fact, I'd create an objet 
> for all the data that needs to be shared during parsing between the parser 
> threads. This object could then have a suitable lock. Anything to avoid 
> reading from a complicated QAbstractItemModel. 

Nothing is reading from the model at all in the background threads, the
background parser gets 1 item as input to generate a list of subitems
from that (i.e. a folder as input and returns a list of newly generated
folder items). It also generates targets and file items along its way
but those are simply new'ed with the apropriate parent object.

Also there are not multiple background threads running here either,
there's 1 thread per project tree and that one runs the parse
recursively until everything is done.

There is (at least in the cmake manager) a _very_ short timeframe in
which a freshly created item is being changed, so in theory its possible
for the GUI thread to fetch a wrong url from such a folder. In reality
however (as the update of the model data is now queued) I doubt you can
manage to hit this timeframe even programatically.

Having a method that generates the items in the GUI thread and attaches
them to the model is possible, but that means the background thread has
to wait for this to happen so it can go into the next deeper level for
parsing making the whole architecture rather complicated. I don't see
enough benefit for going down that path (nor am I willing to implement
it).

Ideally we wouldn't even be doing the project-parsing in a background
thread, but in the GUI thread using a simple timer+queue. But at least
for cmake this again means a major change as we do want the parsing of
the cmake-files to happen in the background as thats a time-consuming
operation.

Andreas

-- 
You may be recognized soon.  Hide.