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