Future of teamwork plugin

David Nolden david.nolden.kdevelop at art-master.de
Wed Jul 4 09:45:30 UTC 2007


Am Mittwoch, 4. Juli 2007 04:21:50 schrieb mchouinard:
> I understand those concept, I might not use them but the point was like I
> say in a later email is when you have to spend more than 15 to 30 minutes
> (and this is way too much time) to understand what a method does, it mean
> from a maintenance point of view that there is something wrong, that's all
> ... it's ok with me if david plan to be around for 5 years to support and
> maintaint this code ;)
> Mathieu

What exact method do you talk about? The point is this:
The teamwork-code uses some concepts all over and over again.

Once you understand those main concepts you will not need 30 minutes to figure 
out what a method does any more.

An example for such a concept:
The most important of that is SafeSharedPtr<>, which is pointers that include 
a locking mechanism.

You do not directly have access to the content of such a pointer, but instead 
you get access to them by implicitly casting them to 
SafeSharedPtr<...>::Locked or LockedSharedPtr<...>. While doing that, the 
content the pointer points to is locked using a mutex, and is freed for 
another thread to use as soon as the LockedSharedPtr<...> is automatically 
destroyed. So as long as you have direct access to the object, it is quite 
sure that you use it exclusively.

If an object cannot be locked within 5 seconds, the LockedSharedPtr<..> will 
have value zero.

That is very safe(I never had even a single threading-related crash), and very 
easy once you got it.

You can access thread-safe parts of an object by omitting the locking by 
calling SafeSharedPtr<...>::unsafe() to get a pointer to the data without any 
mutexes involved. It's called unsafe to discourage its use.

This is the kind of stuff that many parts of the teamwork-plugin are stuffed 
with, but the concept is very good I think, because teamwork uses 
multithreading massively, and this makes that safe.

There are some other unusual concepts, like the message-dispatching system, 
but they were all created to make things easier, not to make them more 
complicated. So anyone who has questions is welcome to ask any time.

I think all those basic things DO have some very basic documentation that at 
least says how they work.

greetings, David





More information about the KDevelop-devel mailing list