basically this reproduces the problem in a simplified setup.
Especially note that we're going through a single instance of the factory,
yet still this single instance 'sees' two different locations of the
class static variable
...but still dynamically linking against the core lib
But the actual template instantiations happen now within the two
compilation units, which are linked statically.
When looking into the symbol table, we can see that the static
field is emitted two times
readelf -W target/clang-static-init -s | c++filt |less
Observations:
- the initial observation was that we get two instances of the config rules service
- obviously this it is *not* the initialisation of a static variable accessed from
multiple compilation units. But the access from two compilation units is crucial
- we can exclude the effect of all other initialisation. It *is* in SingletonSubclass
- we can exclude the effect of dynamic linking. Even two translation units
linked statically exhibit the same problem
rebuild this test case in the research area, to be able to verify with various compilers
by providing a custom copy function one can adjust otherwise non-copyable
elements. This should be used cautionary because dereferencing elements may
poison the cache and thus have some considerable performance impact
(profile this)
using our util::_Fmt front-end helps to reduce the code size,
since all usages rely on a single inclusion of boost::format
including boost::format via header can cause quite some code bloat
NOTE: partial solution, still some further includes to reorganise
initial draft of an RfC to discuss and define the
requirements for other parts of the application to relie on
note: this commit fixes a merge error; the RfC was lost
while combining documentation and code branches
Notably TiddlyWiki provides now a fallback mechanism
in case the saving to a local file fails due to security
restrictions. When this happens, TiddlyWiki generates a
download link pointing to the current content; this way
one is at least able to "save as" through the browser
context menu.
Due to some controversial policy changes in recent Firefox versions
the support for saving to local files was removed. The rationale
given by the Firefox developers was that this is a rarely used
and generally outdated concept; preferrably people shall use
extensions and save to cloud services (!)
Anyway, Jeremy Ruston, the original author of TiddlyWiki, wrote
a Firefox plugin called "TiddlyFox" to work around these
arcane limitations.
this draft fills in the structure how to get from an invocation
of the engine service to the starting of actual CalcStream instances.
Basically the EngineService implementation is repsonsile to
instruct the Segmentation to provide a suitable Dispatcher.
This is necessary since the implementation of the job functions
calls through the VTable of the interface JobClosure. Thus this
interface (and the VTable definition) needs to reside within
some compilation unit linked together with the basic job class.
TODO: move class Job entirely into the Backend
