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