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