Boost logo

Boost :

From: Roland (roland.schwarz_at_[hidden])
Date: 2004-08-08 08:52:35


While considering various ways to get rid of the remaining
intentional memory leak of the tss implementation, I came
upon the following question:

How long may a thread access it's tss storage anyway?
I did not find anything in the documentation about the topic.

Looking into the destructor of thread_specific_ptr reveals
    ~thread_specific_ptr() { reset(); }
which in turn implies, that the thread(s) which are using it
should have already terminated, when the main thread
has exited (called its dtor list).

Now when one has control over the lifetime of the threads
this poses no problem, since they simply need to be terminated
before main() ends.

The situation is completely different when writing a piece
of code (a library) that has to use tss and shall work with
foreign threads too. The library writer in this case has no
control over the lifetime of the threads (native or not).

So I am wondering if it is possible to refine the inner workings
of the thread_specific_ptr without changing the interface
to account for these cases? Perhaps only a static pointer
should be embedded that points to dynamic memory that
will not be touched by destructor calls, but controlled in
lifetime be real thread-detachements. (The last one frees
everything which is really global.)

How is the situation for other libraries, say e.g. pthreads?
Are they allowed to run after main ended? Or is this simply
considered bad programm behaviour?

Any comments?

Roland


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk