Review request: control flow graph plugin

David Nolden zwabel at googlemail.com
Tue Nov 10 11:18:53 UTC 2009


Am Dienstag 10 November 2009 11:30:13 schrieb Esben Mose Hansen:
> On Monday 09 November 2009 23:53:58 Andreas Pakulat wrote:
> > Is there a mutex/lock in the code that protects the above assignment and
> > the usage in the separate threads? If not that might be the reason, no
> > code besides stuff in duchain is thread-safe in kdevelop. So it could
> > very well be that the above assignment isn't done yet while another
> > thread tries to access the variable.
> 
> I didn't find any yesterday, so I really doubt it. Besides, even if there
>  were, what were to prevent this scenario
> 
> 1. Cursor is moved. Project (and duchain stuff) is assigned, thread_weaver
> queue enqueued
> 2. Project close/delete/otherwise invalidated
> 3. thread weaver gets around to actually running the job
> 
> Unless, of course, the threadweaver somehow knows about the projects and
> ensures that they are appropriately canceled when this happens. Even with
> this, I don't see how the DUChain pointers could survive from 1. to 3.

It is safe to keep references to duchain objects across lock phases if:
- They are held through a "DUChainPointer", "IndexedDeclaration", or 
"IndexedDUContext" object. In those cases however the objects will become zero 
if they were deleted+recreated by the background-parser in the meantime.

So a better option would be either gathering the objects in the background-
thread with a read-lock held, or referencing them through a DeclarationId 
object.

Greetings, David




More information about the KDevelop-devel mailing list