Using DUChain from the main thread

[Hamish Rodda]

Hi,

Now that we have heaps of great information in the DUChain, it's important to 
be able to access it safely from the main thread so that we can do Cool 
Stuff(TM) with it.  Such as: code completion, class browser, etc, etc.

I came up with an idea for how this could be achieved, see if you like it:

**** Background:
Currently, the duchain is accessed from the main thread by the DUChain users 
(eg, the duchainviewer).  They receive notifications directly from the 
parsing thread about changes, and thus has to protect themselves during a 
notification, as eg. it could also be within a request from the item model 
system.  This makes it pretty hard to comply with the item model's 
requirements for item addition, etc.  So, we end up having to create a 
separate tree for each node in the chain, and make sure it is not deleted 
each time it is accessed.  Any lengthy code execution here will block the 
parsing thread.  To properly comply with the item model's requirements, a 
complex system would be required.

**** Idea:
As we want to remove as much of the tricky code from the DUChain users (eg 
class browser) as possible, make sure that the notifications are delivered 
within the thread that the DUChain user resides in.  This is achieved by the 
following:

1) each time a change is made, the duchain emits a signal from the parser's 
thread
2) this is connected to by users, and received in their thread, not the 
parser's thread (Qt::QueuedConnection)
3) a separate, private signal is emitted after a duchain object is about to be 
deleted, and then the object is deleted in the main thread.

The guarantees that are provided to the DUChain user:
1) objects will not be deleted prior to you receiving a signal that warns you 
they are about to be deleted
2) any other detail about them may change, unless you hold a read-lock over 
the duchain.

This still requires a separate tree of objects, but hopefully will be less 
complicated and easier to maintain.

The main drawback that I can see with this technique is that deletion of 
objects will be slower, as two signals have to be emitted for each object 
deletion.  However, I would think this will be an uncommon use, and when mass 
deletions are required, we could turn the notification system off and send a 
reset() signal.

Well, I hope that's clear... anyone with ideas / comments please speak up...

Cheers,
Hamish
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20071030/7b7a45c0/attachment.sig>