[Kst] Architectural changes
netterfield at astro.utoronto.ca
Thu Dec 10 16:16:51 CET 2009
After going through in detail the use of <Object>Ptrs in kst last week, I
found and removed a couple places that were causing some our memory leaks and
crashes, or at least causing KstSharedPtr to not delete things when it should
(and to delete things when it shouldn't).
The Store is basically a list, with a couple convenience functions thrown in
(template functions to create and find objects). I think that this is how it
should probably stay.
Kst uses KstSharedPtr, which does in fact seem to work just fine. I don't
think we should change that either.
(Note: KstSharedPtr has the huge advantage over a QSharedPtr that it stores
its reference count in the object itself, so a KstSharedPtr can be converted
into a bare pointer, passed somewhere, and converted back into a KstSharedPtr,
and the reference count is happily carried over. Not so for QSharedPtr, which
holds the reference count in the pointer itself.)
The last big 'under-the-hood' work is related to locking. Currently, we are
not multi-threaded, except for some stuff related to data-source
initialization, so any locking troubles we might have, we don't currently
face. This will need to be fixed. I propose we delay this until after 2.0.
So: From now to 2.0, we should work only on critical bug fixes and critical
or very easy feature fixes, which a goal of a 2.0 release on the weekend of
The exception to this would be if we find a reason we would need to do an API
change to data-sources or plugins, in which case the Jan 1 release would be
More information about the Kst