Re: [Boost-users] Manually cleaning up TSS data in boost 1.49

Subject: Re: [Boost-users] Manually cleaning up TSS data in boost 1.49
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-11-26 18:05:20

Le 26/11/12 22:12, Andrew Harvey a écrit :
> Hi,
>
> I am using boost::thread for a plug-in that is loaded by a third-party 
> Linux application. I have no control over the host's threading or when 
> it chooses to unload my code.
>
> Unfortunately I experience a crash every time the host thread unloads 
> the .so and terminates. I get the following backtrace:
>
> (gdb) bt
> #0  0x00007fffde12c460 in ?? ()
> #1  0x00000032cf607889 in start_thread () from /lib64/libpthread.so.0
> #2  0x00000032cf2e5ccd in clone () from /lib64/libc.so.6
>
> Not much to go on...
>
There are several limitation on Boost.Thread that could make this error. 
I've not yet the knowledge to fix them.
> I am pretty confident the crash is happening in a pthread key 
> destructor registered by Boost. The only parts of the boost::thread 
> library I am currently using are the synchronization classes:
>
> shared_mutex,
> shared_lock,
> unique_lock,
> upgrade_lock,
> upgrade_to_unique_lock
>
> I'm not directly using any thread-specific storage myself.
>
> What I would like to do is force boost to call its TSS destructor in 
> my plug-in's destroy_dso() function. Is this at all possible?
>
>
I don't know which version are you using. For the next release I'm 
preparing a version that could work without thread interruptions. This 
should allow to use the synchronization part independently of the 
boost::thread part, so maybe it could be possible to use the library as 
a header only one. I will try to test it soon. You could check it on 
your side, by defining
BOOST_THREAD_VERSION to 3 and define 
BOOST_THREAD_DONT_PROVIDE_INTERRUPTIONS. You will need to link 
additionally to boost_system and boost_chrono if you are using the 
Boost.Chrono time related interface.

HTH,
Vicente