[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 219105] KDevelop crashed at quit
From:       Andreas Pakulat <apaku () gmx ! de>
Date:       2010-01-13 20:07:40
Message-ID: 20100113200743.782192F9F2 () immanuel ! kde ! org
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=219105





--- Comment #14 from Andreas Pakulat <apaku gmx de>  2010-01-13 21:04:54 ---
(In reply to comment #13)
> Hm let me rephrase to make my intention clearer:
> 
> If we'd use a QSharedPointer and let it decide when to delete the plugin and
> when not, i.e. no manual qDeleteAll / deleteLater in any controllers, we should
> be on the safe side, no? And I picked IProject just because it's the base
> class, I dunno what would happen if I have:

IProject is not a base class for any plugins. You probably mean
IProjectFileManager.

And no, thats not a solution, at least not without a complete redesign. Right
now the Plugincontroller is the core instance that loads and unloads plugins.
If we'd use QSharedPointer then you'd have plugin instances around that are not
tracked anymore by the plugincontroller. So you can easily get into the
situation that something asks the plugincontroller to load plugin X which is
actually not yet unloaded/deleted because some other object still has a
reference to it. Now you get two instances of the same plugin loaded twice,
this is a major change in our plugin system and breaks the promise to plugin
authors that only 1 plugin instance will ever be running. This can easily lead
to race-conditions when these instances are trying to write some data (in some
global object or just config files).

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]