Hi, I don't know if this is a known bug or not: When using thread_specific_ptr's, if at any time later in the program the total tss data items drops to zero, it is no longer possible to use tss data. Example: ----------------- #include <boost/test/minimal.hpp> #include <boost/thread/tss.hpp> using namespace boost; int test_main(int, char*[]) { { thread_specific_ptr<int> pi; } try { thread_specific_ptr<int> pi; } catch (thread_resource_error&) { BOOST_FAIL("Can't use TSS any longer after initial usage dropped to zero!"); } return 0; } --------------------- The above program fails when using Boost from the RC_1_34_0 branch + msvc 8.0 under XP SP2 (my copy of the 1.34 branch is not very recent - from January this year). Haven't tried other combinations. The actual problem seems to be related to tss deinit based on reference counting and init based on once_init, IIUC. Best regards, Johan Nilsson
Johan Nilsson wrote:
Hi,
I don't know if this is a known bug or not:
When using thread_specific_ptr's, if at any time later in the program the total tss data items drops to zero, it is no longer possible to use tss data.
How can this happen in real code? thread_specific_ptr instances should always have static storage duration. The only legitimate situation appears to be to load and then unload a DLL that uses thread_specific_ptr.
Peter Dimov wrote:
Johan Nilsson wrote:
Hi,
I don't know if this is a known bug or not:
When using thread_specific_ptr's, if at any time later in the program the total tss data items drops to zero, it is no longer possible to use tss data.
How can this happen in real code? thread_specific_ptr instances should always have static storage duration.
Yes, _should_. Still, the behaviour isn't very intuitive when you look at my example.
The only legitimate situation appears to be to load and then unload a DLL that uses thread_specific_ptr.
Dynamically allocated thread_specific_ptrs (raw pointer to tss ptr). Don't ask me for the rationale, see below. I noticed the behaviour when using a third-party library that uses a global init/deinit function. In the init function, a library internal thread_specific_ptr is alloc'd and in the deinit it was deleted. One of the provided functional tests exercised the init/deinit stuff and crashed at the second, explicit, init call. / Johan
participants (2)
-
Johan Nilsson -
Peter Dimov