The call to uninitialize would be done inside of OpenEXR, and not by any
calling plugin. Therefore would only be called once IlmImf.so unloads,
which would only happen when all users are done with it.
Basically, this function should both be internal to OpenEXR and OpenEXR
alone should be responsible.
This also alleviates a potential race-condition with using a local
static Mutex in staticInitialize -- which, prior to C++11 is not
guaranteed to be thread-safe -- since DSO load sequences are guaranteed
to be single-threaded (although another fix is to move the Mutex to file
scope).
Hope this clears it up.
- ½
On 13-11-06 03:25 PM, Peter Hillman wrote:
Calling Uninitialize automatically seems dangerous. What happens if a
package loads two plugins, both of which are dependent on OpenEXR? If
only one is unloaded, there's a danger it would unitialize the
attributes for the other, causing a segfault when it tries to parse a
header. Alternatively, if both are unloaded, the second might try to
free memory already freed by the first.
It seems safer only to call this function manually, and only in a
build intended for leak analysis, since the memory returned is
insignificant.
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
