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

List:       koffice-devel
Subject:    Re: [patch] koffice/libs/: port K3StaticDeleter to K_GLOBAL_STATIC
From:       Jaroslaw Staniek <js () iidea ! pl>
Date:       2008-08-27 15:19:51
Message-ID: 48B57097.10409 () iidea ! pl
[Download RAW message or body]

Thomas Zander said the following, On 2008-08-27 14:54:
> On Wednesday 27. August 2008 12:30:48 Jaroslaw Staniek wrote:
>>> The init and the constructor are separate for a good reason. The init
>>> fetches all the plugins and constructs them. So calling init can take
>>> quite some time.
>>> All the plugins do thing too, including calling another singleton. Which
>>> will then create lots of plugins there. And those plugins may use our
>>> singleton.  And you have a loop.
>> K3StaticDeleter does not protect us for this - do you accept that the
>> singleton is accessed in somewhat uninitialized state (before init() ends)?
> 
> We have a guard that init is called only once, so subsequent calls to the 
> somewhat uninitialized repository is ok.

any idea where exactly?

>> So I propose to keep init() and go with K_GLOBAL_STATIC; which works just
>> like the old static deleter in this case. Plus appropriate comments would
>> be added on why we need init().
>>
>> Example:
>>
>> KoShapeRegistry* KoShapeRegistry::instance()
>> {
>>      K_GLOBAL_STATIC(KoShapeRegistry, s_singleton)
>>      if (!s_singleton.exists())
>>         s_singleton->init();
>>      return s_singleton;
>> }
> 
> Hmm, where does 'exists()' come from?  I can't find it in the API docs.

from kglobal.h, K_GLOBAL_STATIC_WITH_ARGS macro

> If this code makes sure that only the first time the singleton is created will 
> it be initialized; thats exactly what we should have.

It does, assuming there's no race condition (due to multithreaded use).

> If so, sounds great :)
> 
>> BTW, looks like neither the K3StaticDeleter solution nor K_GLOBAL_STATIC
>> solution is thread-safe - init() could be called many times...
> 
> KOffice is not made to be threadsafe. (just small parts are ;)

Would be great to be able to use ODF libs (and other stuff) in threads.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]