SmartRange revisions in ParseJobs

Milian Wolff mail at milianw.de
Sat Feb 20 12:58:52 UTC 2010


David Nolden, 20.02.2010:
> Am Freitag 19 Februar 2010 16:18:24 schrieb Milian Wolff:
> > Hey all, esp. David:
> > 
> > With recent trunk you'll see that Cristoph added a warning when the
> > clearRevision is called from the wrong thread (the locks are apparently
> > 
> >  per- thread else all kind of havoc could happen).
> > 
> > The parsejobs do useRevision in contentsAvailableFromEditor but
> > 
> >  clearRevision in their dtor, both are in different threads (form in the
> >  background due to backgroundparser, latter somewhere else due to
> >  signal/slot connections).
> > 
> > So how should we fix that properly in KDevelop? Introduce something like
> > a SmartRevisionLocker that does clearRevision when it gets closed down,
> > and
> > 
> >  set this up in the ::run() of each ParseJob? I can't see how it could be
> >  completely hidden from the implementation of a language parsejob
> >  though...
> > 
> > Ideas?
> 
> Hmm, the real solution would be changing the API around useRevision and
> clearRevision. However as that's not possible, I guess the only solution
> will be adding a function like "finished()" to ParseJob which does the
> cleanup, and making sure that it's always called within the parse-thread
> when the parse-job is ready.
> 
> Yes, ideally it should be completely hidden from the parse-job
> implementation itself. Maybe the thread-weaver has some API that could be
> used for that?

OK, thanks I'll take a look at it and implement it together with Christoph.
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100220/4e01648c/attachment.sig>


More information about the KDevelop-devel mailing list