Singleton problems

[Freddie Akeroyd]

It looks like you can create more than one instance of a singleton on Windows in Mandid, but not on linux. I believe this is due to all classes and data being marked DLLExport and none DLLImport so they all create a separate instance variable for the singleton.

[Freddie Akeroyd]

(In [724]) * Add in option on scons windows debug build (pass debug=1)

• Add IN_MANTID_* defines to the CPP - these are needed to allow a correct selection of either DLLExport or DLLImport
• Update various singleton classes to use DLLExport/DLLImport

Refs #96.

[Freddie Akeroyd]

(In [725]) Change if to ifdef in a few places. Refs #96.

[Freddie Akeroyd]

(In [726]) Add DLLImport to LibraryManager. Refs #96.

[Freddie Akeroyd]

(In [727]) Update Visual Studio projects with new IN_MANTID_* defines. Refs #96.

[Freddie Akeroyd]

(In [728]) This file is no longer used. Refs #96.

[Matt Clarke]

(In [729]) Refs #96. Changed AlgorithmFactory to use a singleton holder. The export-import problem was solved by forward declaring the template specialisation.

[Matt Clarke]

(In [730]) Refs #96. Changed LibraryManager to use a singleton holder.

[Matt Clarke]

(In [731]) Refs #96

[Matt Clarke]

(In [732]) Refs #96. Changed AnalysisDataService to use a singleton holder.

[Matt Clarke]

(In [733]) Refs #96. Changed ConfigService to use a singleton holder.

[Freddie Akeroyd]

(In [734]) Temporary fix for namespace instantiation probelm. SingletonHolder is in Mantid::Kernel and so is not allowed to instantiate objects in Mantid::API under the latest namespace scope rules followed by gcc 4.1

Refs #96

[Matt Clarke]

(In [736]) Refs #96. Changed WorkspaceFactory to use a singleton holder.

[Matt Clarke]

(In [737]) Refs #96. Changed FrameworkManager to use a singleton holder. Hopefully, this is the last of the existing singletons!

[Matt Clarke]

(In [738]) Refs #96. Tided up the code. Added DllExport.h to API and Kernel - this contains the #define information for any exports from the dll.

[Matt Clarke]

(In [739]) Refs #96. Forgot to add file!!!

[Freddie Akeroyd]

(In [748]) Comment out POCO logging of destruction ... it is safe to use std::cout etc in a singleton destructor, but not POCO. Refs #96.

[Freddie Akeroyd]

(In [749]) Remove logging of destruction. Refs #96.

[Freddie Akeroyd]

(In [757]) Fix crash on program termination, which was caused by the LibraryManger instance being closed before the dynamically loaded Algorithm had been destroyed. A better solution would be to implement Singleton longevity as described in Andrei Alexandrescu's book Refs #96.

[Freddie Akeroyd]

(In [760]) Workaround for logging problem. The static instance of the Logger gets created at a random time and causes problems for singletons that get created as part of other objects static constrcutors. As a workaround I have moved the Logger instance into the class itself for singletons.

Refs #96.

[Freddie Akeroyd]

(In [764]) The C atexit() function seems to have a bug and not always destroy singletons in the correct order. Fix involves implementing our own atexit() handler for singletons. Refs #96.

[Freddie Akeroyd]

(In [765]) Add DllExport to new singleton functions. Refs #96.

[Freddie Akeroyd]

(In [766]) Document singleton class. Refs #96.

[Stuart Campbell]

This ticket has been transferred to github issue ​944