Overview
Features
Download
Documentation
Community
Add-Ons & Services
The POCO C++ Libraries Blog

Library AutoiNEATialization

Filed under: Development,Tips & Tricks by alex at 18:00

In some of POCO libraries (Net on Windows, Data back-ends, Crypto, NetSSL …), there is a need for early library initialization. This task has been done so far in a couple of ways (neither elegant) – we either

  • (1) call initialization (repeatedly) from some strategic points in the library (Net, SSL) that we know will get hit early, or
  • (2) mandate early explicit call (un)initialization (Data back-ends) early from user code.

So, the question here is: can we (and, if the answer is yes, how?) improve the current state?

  • Problem: do tasks early at application init or shared library load, ensuring they are executed prior to any other activity depending on them.
  • Examples: Windows network initialization, DB back-end registration with front-end registry …
  • Solution: looks simple at first, then not so simple when the reality of (1) dynamic/static linkage (on Windows in particular), (2) static variable initialization timing/order and (3) dynamic library loading order (e.g. Data and back-end libraries) hits.

At first, one would think this (SQLite back-end with abbreviated names used as an example here) will do the trick:

// Connector.h:
struct SQLite_API SQLiteRegistrator
{

SQLiteRegistrator()
{
SQLite::Connector::registerConnector();
}

~SQLiteRegistrator()
{
SQLite::Connector::unregisterConnector();
}

};

extern "C" struct SQLite_API SQLiteRegistrator sqliteRegistrator;

// Connector.cpp:
SQLiteRegistrator sqliteRegistrator;

Alas, MSVC will disregard your wishes in both static and dynamic library builds when it sees that the registrator is “not used” anywhere. Luckily, there’s a way to force the linkage:

#pragma(comment (linker, "/include:_sqliteRegistrator")

With some ifdef-ing for 64-bit (no underscore decoration) and dynamic exports, it turns out that the task is achievable:

#pragma(comment (linker, "/export:sqliteRegistrator")

So, now we have a way to force initialization without having to explicitly call registerConnector from user code (or peppering library with initialization code).

Details are in GitHub repo (Net and Data back-ends only at the time of this writing).

This modification was tested on Windows, Mac and Linux, static and shared builds; I’m putting a word out to hear comments and make sure I did not miss something important, so suggestions are more than welcome. I’d like to have this in the upcoming 1.5.2.

2 Comments »
  1. just make sure its not prone to static initializer fiasco. some user library that uses one of those POCO libraries uses the same static init pattern, may be initialized before them. at least make some explicit POCO_init available for them to use. but the library may not be aware of the need for explicit init, until some static initializer fiasco symptoms begin. singleton initializers are the best way to go, basically the (1) option, call initialization (repeatedly)

    Comment by dshor on March 21, 2013, 13:58

  2. Explicit calls are obviously available through initialization object, eg:

    SQLite::Connector::registerConnector();

    Calling initialization repeatedly is what I was trying to avoid in the first place because that is something that is needed exactly once at startup and should not be called repeatedly forever.

    Comment by alex on April 15, 2013, 09:29

RSS RSS feed for comments on this post. TrackBack URI

Leave a comment