[Insight-developers] Static initialization in itkImageSource causes early registration of ITKIOFactory

Wed Apr 3 14:13:02 EDT 2013

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.

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 <blowekamp at mail.nih.gov>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 <bill.lorensen at gmail.com>
> 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 <
> jchris.fillionr at kitware.com> 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 <blowekamp at mail.nih.gov
>> > 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 <
>>> jchris.fillionr at kitware.com> 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
>>>
>>>
>>> <https://github.com/Kitware/ITK/blob/4c47e7d672bad5d83b92c2df5f293cca618e2740/Modules/Core/Common/src/itkImageSource.cxx#L27>
>>> --
>>> +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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20130403/9c168c36/attachment.htm>