On Apr 3, 2013, at 2:13 PM, Jean-Christophe Fillion-Robin 
<[email protected]> wrote:

> 1) A possible way of checking this would be to check if an env variable named 
> ITK_OBJECT_FACTORY_BASE_INITIALIZE_VERBOSE is defined to 1, if it is the 
> case, the number of registered factory would be displayed in the 
> "ObjectFactoryBase::Initialize()" methods.
> 
> Then writing a hello world program linking against ITK, would allow to check 
> if the "hello world" string is displayed before or after static 
> initialization.

This is a static method so the itkDebugMacro this does not work.

I tried using getenv, and in the ObjectFactoryBase::Initialize() method, and it 
causes a segfault during static initialization. 

Still looking into other options...

> 
> 2) I think the addition of a ITKFactoryRegistration shared library would be 
> backward compatible. Application would be either using their inside hack or 
> calling the method provided by ITK allowing to register the factories. Let's 
> also note that all of this would be needed only if the variable 
> ITK_NO_IO_FACTORY_REGISTER_MANAGER is set to True.
> 
> I really think this would benefit every application loading plugin. 
> 
> 3) A different approach would be to check if a given factory is already 
> loaded and ensure that no duplicate factory are registered.
> 
> Let me know what you think.
> 
> Thanks
> Jc
> 
> 
> On Wed, Apr 3, 2013 at 1:25 PM, Bradley Lowekamp <[email protected]> 
> wrote:
> Bill,
> 
> There is currently no an obvious way I see to check this. If you call a 
> method of the ObjectFactory to ask how many object are registered, it will do 
> the initialization if it wasn't before.
> 
> Now a new method could be added, to check if the ObjectFactory has been 
> initialized. But I recall there was quite a lot of issues with the class on 
> when the initialization should occur and how to check if it needs to be done.
> 
> Brad
> 
> On Apr 3, 2013, at 12:35 PM, Bill Lorensen <[email protected]> wrote:
> 
>> Brad,
>> 
>> Is there a way we can test for this in ITK? Better we find it before our 
>> customers.
>> 
>> Bill
>> 
>> 
>> On Wed, Apr 3, 2013 at 12:11 PM, Jean-Christophe Fillion-Robin 
>> <[email protected]> wrote:
>> Thanks Brad for looking at the issue so quickly :)
>> 
>> I reviewed your patch in gerrit and posted comment.
>> 
>> Thanks
>> Jc
>> 
>> 
>> On Wed, Apr 3, 2013 at 11:33 AM, Bradley Lowekamp <[email protected]> 
>> wrote:
>> Hello JC,
>> 
>> This is quite an interesting side-effect of the changes I introduced.
>> 
>> I am glad that you were able to figure this out. For a variety of reasons, 
>> it's likely a very bad thing for all that to occur during static 
>> initialization in ITK. So it certainly needs to be fixed.
>> 
>> I agree that lazy initialization is the way to go. Unfortunately it needs to 
>> be thread safe so its a little more completed.
>> 
>> ITKv4 performs the factory initialization when the user creates the first 
>> ITK object.  And that changed with this patch, and need to be fixed.
>> 
>> CONCLUSION:
>> 
>> Inside ITK, we can not use statically initialized ITK object.
>> 
>> Brad
>> 
>> On Apr 3, 2013, at 10:54 AM, Jean-Christophe Fillion-Robin 
>> <[email protected]> wrote:
>> 
>>> Hi Brad, 
>>> 
>>> Following commit 4c47e7d [1] of February 19th and commit defb9c1 [2] of 
>>> March 1st, due to static initialization, the initialization of 
>>> ObjectFactory  now happens when ITK shared library are loaded [3][4].
>>> 
>>> This caused a regression in Slicer where the ObjectFactory were expected to 
>>> be loaded while attempting to load an image for the first time. 
>>> 
>>> In Slicer case, the environment variable ITK_AUTOLOAD_PATH was set during 
>>> the initialization of the qSlicerCoreApplication, which is now too late.
>>> 
>>> By commenting line where a new ImageRegionSplitterSlowDimension is 
>>> instantiated [5][6] and updating the method "GetImageRegionSplitter / 
>>> GetGlobalDefaultSplitter" to return 0 [7][8], the initialization can happen 
>>> on demand instead of when ITK libraries are loaded.
>>> 
>>> An easy solution for us would be to ensure the "ITK_AUTOLOAD_PATH" 
>>> environment variable is set in the application launcher for Windows and 
>>> Linux application and set in Info.plist file associated with the 
>>> application bundle on MacOSX [9]
>>> 
>>> To provide more details, within Slicer we set the CMake variable 
>>> ITK_NO_IO_FACTORY_REGISTER_MANAGER before doing an 
>>> "include(${ITK_USE_FILE}) so that IOFactory are loaded only by calling the 
>>> method "itkFactoryRegistration" associated with a shared library we named 
>>> ITKFactoryRegistration. This approach allowed us to disable the automatic 
>>> registration of factory in selected part of the code. More details here [10]
>>> 
>>> It seems the new ITK commits 4c47e7d and defb9c1 prevent from completely 
>>> leveraging the use of ITK_NO_IO_FACTORY_REGISTER_MANAGER variable, the code 
>>> should probably be updated to consider this.
>>> 
>>> 
>>> Let me know what you think.
>>> 
>>> Thanks
>>> Jc
>>> 
>>> 
>>> [1] https://github.com/Kitware/ITK/commit/4c47e7d
>>> [2] https://github.com/Kitware/ITK/commit/defb9c1
>>> [3] 
>>> https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkImageSource.cxx#L27
>>> [4] 
>>> https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkObjectFactoryBase.cxx#L142-144
>>> [5] 
>>> https://github.com/Kitware/ITK/blob/defb9c1d084c8d55df61947587427839f9968ecf/Modules/IO/ImageBase/src/itkImageIOBase.cxx#L760
>>> [6] 
>>> https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkImageSource.cxx#L27
>>> [7] 
>>> https://github.com/Kitware/ITK/blob/defb9c1d084c8d55df61947587427839f9968ecf/Modules/IO/ImageBase/src/itkImageIOBase.cxx#L765
>>> [8] 
>>> https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkImageSource.cxx#L32
>>> [9] 
>>> http://www.herzbube.ch/blog/2009/01/how-set-environment-variables-mac-os-x-applications
>>> [10] https://github.com/Slicer/Slicer/commit/03b8961
>>> 
>>> -- 
>>> +1 919 869 8849
>>> _______________________________________________
>>> Powered by www.kitware.com
>>> 
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>> 
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://kitware.com/products/protraining.php
>>> 
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>> 
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.itk.org/mailman/listinfo/insight-developers
>> 
>> 
>> 
>> 
>> -- 
>> +1 919 869 8849
>> 
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.php
>> 
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>> 
>> 
>> 
>> 
>> -- 
>> Unpaid intern in BillsBasement at noware dot com
> 
> 
> 
> 
> -- 
> +1 919 869 8849

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://www.itk.org/mailman/listinfo/insight-developers

Reply via email to