Threadsafe project model

[David Nolden]

2010/7/16 Andreas Pakulat <apaku at gmx.de>:
> 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).
In the danger of repeating myself, why not simply use a "{
ForegroundLock lock; generate items and add them to the tree; }" ?
Since the GUI thread should be mostly idle, this shouldn't slow down
the parsing, as long as it's done only once-per-file and/or
once-per-folder.

> 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.

It should definitely be done in the background, because there is a lot
of I/O, and that can really kill the UI responsiveness.

Greetings, David