Re: flyweights, nested flyweights and shared libraries

From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2021-02-23 18:12:50

El 23/02/2021 a las 10:59, Andreas Buykx via Boost-users escribió:
>
> Hello Joaquín,
>
Hi, please don't top-post, see:

https://www.boost.org/community/policy.html#quoting

> Thanks for your help. This morning it dawned on me what you meant with 
> the remark
> about the destruction: I implemented all constructors as explicit 
> default in the cpp-file but
> I had forgotten to do that for the destructor. Now everything runs 
> like a breeze, except for
> one situation where I get an assertion:
>
> boost::flyweights::detail::recursive_lightweight_mutex::scoped_lock::scoped_lock(boost::flyweights::detail::recursive_lightweight_mutex 
> &): Assertion `pthread_mutex_lock(&m_)==0' failed.
>
> This exception is raised while destroying the nested flyweight wrapper 
> from the nesting
> flyweight wrapper, but only in one of my many test cases where these 
> flyweight wrappers
> are used. Do you have any suggestions on why this might happen?
>
Umm.. Do you have any *global* static variable of type 
nesting_flyweight? If so, you
may be running into the sort of static data initialization issues 
described at:

https://www.boost.org/ibs/flyweight/doc/tutorial/technical.html#static_init

To see if this is the problem, insert

static your_nested_flyweight_type::initializer  fwinit;

before the potentially offending global varable.

> Regarding the use of intermodule_holder I mistook a link error for a 
> compile error:
>
> /opt/rh/devtoolset-6/root/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/ld: 
> Test/appz/ppf/unittests/model/results/CMakeFiles/unittest_PpfModelResultUnitTest.dir/PpfResultCaseUnitTest.cpp.o: 
> undefined reference to symbol 'shm_unlink@@GLIBC_2.2.5'
>
> //lib64/librt.so.1: error adding symbols: DSO missing from command line
>
I'm no Linux expert, does this article help?

https://stackoverflow.com/questions/9923495/undefined-reference-shm-open-already-add-lrt-flag-here

> All that aside: you mention that getting intermodule_holder is the 
> preferred option,
> but given that it’s “… |intermodule_holder| is considerably more onerous
> than |static_holder| in terms of compilation times and introduces a
> non-negligible overhead at program start-up …”, isn’t wrapping the 
> flyweight
> in an accessor class (especially your templated construct) at least as 
> good an option
> that maybe deserves a mention in the documentation?
>
I'm not sure this is robust enough for general use. What happens if two 
different modules
libA and libB both export the same, say, dll_flyweight<std::string> type?
>
> Thanks again for your help,
>
> Andreas
>
Joaquín M López Muñoz