[ITK-dev] ITK+static+wrapping [ref: 21857 "Enable singleton program global timestamp"]

Isaiah Norton isaiah.norton at gmail.com
Fri Dec 16 16:24:43 EST 2016


I was added as a reviewer on #21857 [1], but my comment is more general, so
I don't think gerrit is the best place for it.

The background of that merge request is [2], where a user demonstrated
inconsistent modification times when objects are modified by functions from
different modules, via Python, with ITK compiled in static library mode.
The underlying cause is that each module has a separate, private instance
of the GlobalTimeStamp, so the operations increment different counter
variables.

The proposed solution in [1] is to provide a singleton-like object with a
settable internal pointer, initialized by the Python loader to point to a
single instance in ITKCommon.

The technical implementation looks ok, but the original situation in [2] is
strange:

What is the rationale behind creating so many separate, statically-linked
Python modules? (78 `_ITK*Python.so` files on my machine). Creating a
single bundle instead should resolve the original issue, and might also
reduce the size of the final library [3].

Additionally, I am wondering if cross-module `dynamic_cast` works correctly
in the current situation -- because the typeinfos in each static module .so
have different addresses [4]. (I'm not sure how to create a situation to
test this from Python)

Best,
Isaiah

[1] http://review.source.kitware.com/#/c/21857/4
[2] https://issues.itk.org/jira/browse/ITK-3456

[3] As a point of reference, the total size of the static `_ITK*Python.so`
files on my mac is about 670MB. If I manually link everything into a single
file, the size drops to about 430MB, presumably due to deduplication of
symbols. Further reduction might be possible: there are still many
duplicate symbols which may not be merged due to differing offsets.

[4] https://gist.github.com/ihnorton/6691645ede869d6bc6c25b143fbf3003
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161216/2d245f44/attachment.html>


More information about the Insight-developers mailing list