Threadsafe project model

[Andreas Pakulat]

On 16.07.10 13:57:47, David Nolden wrote:
> 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; }" ?

a) there's no foreground lock (in master)
b) its not necessary
c) it wouldn't solve the issue that Esben raised, namely reading data
from the items _after_ they've been created.

And not to mention that you'd have to go around fixing _every_ project
managers code to do that, while simply using a queued-connection for the
gui-related changes (i.e. emitting the model signals) can be done inside
the items codebase once and for all.

Really, creating items and adding them to the model from a background
thread is already solved now, its done, no need for further discussion.

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

I guess I wasn't clear, the code that parses cmake files and generates
the information necessary to build the tree definetly belongs into a
separate thread. In fact I'd love this to be a plain old
language-parse-job. However the generation of items from this data is
really simple and thats something that could be done in the GUI thread
rather easily.

Anyway, nothing I'm going to change anytime soon as long as generating
and setting up items in a background thread still works.

Andreas

-- 
Better hope the life-inspector doesn't come around while you have your
life in such a mess.