KConfig + KComponentData (Re: KInstance redesign)

Matthias Kretz kretz at kde.org
Sun Jan 21 11:09:47 GMT 2007

a suggestion:
- remove the possibility to get a KConfig object from KComponentData, only the 
KSharedConfig object is returned.
- the refcount of KComponentData's KSharedConfig object is taken into account:
When KCD creates the KSharedConfig object the latter will inc the refcount of 
the KCD. Therefore when the refcount of the KCD reaches one it looks at the 
refcount of the contained KSharedConfig and delete it if it is one as well. 
If the refcount of the KSharedConfig object is greater than 1 nothing happens 
until the refcount of KSharedConfig reaches 1. Then KSharedConfig tells its 
KCD that its refcount is at one...

not necessary, but nice IMHO (This would break _a lot_ of code. I'm not sure 
it's worth it):
- remove the ::Ptr part of KSharedConfig and make it explicitly shared (well, 
detaching doesn't make much sense for KSharedConfig, though, no?)
- make KConfig an explicitly shared class but different from KSharedConfig in 
that multiple (different/detached) objects may reference the same config file 
with the in memory reprensentation not having to be the same.

On Saturday 20 January 2007 23:25, Matthias Kretz wrote:
> If the KConfig object doesn't increase the refcount on KComponentData then
> KComponentData can go away before the KConfig object is deleted. Which is
> what I wanted to fix.
> Currently you can create your own KConfig object, use KSharedConfig and
> some code uses the KConfig object from KGlobal::config() or
> KInstance::config().
> The problematic one is the latter. After KComponentData created its KConfig
> object it could deref its own refcount so that when nobody references the
> KComponentData object anymore (except the KConfig object) the KConfig
> object gets deleted. The reason this won't work is that many programs might
> keep a pointer to this KConfig object. A dangling pointer then...
> How about making all KConfig objects refcounted as well? Like KSharedConfig
> already is? That way KComponentData could wait with dying until the
> refcount of its KConfig object reaches 1.

Matthias Kretz (Germany)                            <><
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070121/b6262574/attachment.sig>

More information about the kde-core-devel mailing list