Status

Work in progress to be delivered as part of 2022JUN:

Background

ACS makes use of Loki and ACE libraries to implement singleton functionalities. Loki is an old library providing support for singleton; on the other hand ACE is a maintained middleware for portability which also offers singleton implementation because it was not officially offered by C++ or Boost years ago. The problem is that the support for Loki library was discontinued and it is becoming a legacy software in ACS. These days the standard C++ library provides a mechanism for clean and thread-safe singleton implementations based on static variables, hence it would make sense to migrate the existing singletons to one of the two clean mechanisms available depending on the requirements.

...

• Define a static variable on the class, which is an instance of itself.
  • This has the limitation that the class is initialized at startup
  and no
  • No parameters can be
  loaded up
  • passed to the constructor other than static ones
  • Can't be recreated unless the class is compatible with std::swap mechanics
• Define a static variable on the class, which is a pointer to an instance of itself. Here the limitation is removed, but this forces us to create/destroy the instance
  • Can be created/recreated with parameters, giving more freedom, but not being a true singleton
  • We also have to handle the variable's life cycle manually or wrap around a smart pointer
  • Thread-safe is not automatic and needs to be considered when creating/recreating/destroying
• Define a static variable on a singleton method such as <class>::instance(), <class>::get(), etc.
  • Will be created the first time the method is called and be destroyed when the process exits
  • Parameters can be passed either from static or runtime context
  • Can't be recreated unless the class is compatible with std::swap mechanics
  • Thread-safe is assured by the standard on creation/destruction

Implementation

The implementation is ultimately based on the third alternative respecting the standard API and allowing for a smoother use by the communityfirst and third alternatives depending on the requirements. The three alternatives are correct options depending on the requirements, and we chose the simpler ones when possible. The implementation is marked for 2022APR 2022JUN release. Details can be found in the ticket: