Re: [boost] Re: alternative thread_specific_ptr idea

From: Martin Wille (mw8329_at_[hidden])
Date: 2003-11-11 15:49:50

Alexander Terekhov wrote:

> Martin Wille wrote:
> [...]
> 
>>A downside of this approach is that operator->(),
>>operator*() and .reset(p) (for p!=0) for this
>>implementation could throw (due the underlying vector
>>failing to be expanded). However, .get(), .release(),
>>.reset(0) and the dtor could be made nothrow.
> 
> 
> .reset(0) is aka .dispose() and it has throw()-nothing 
> ES. operator->() and operator*() shall simply assert() 
> on .get() and also be nothrow. 

.dispose()? I was referring to the thread_specific_pointer
interface described in http://tinyurl.com/ul62
With "could be made nothrow" I was referring to the
alternative tsp. .release() and .reset(0) and the dtor
have to be be nothrow, of course.

I see, there was some misunderstanding about how I thought
.get() could be made nothrow. Since what I suggested is
not part of a native threading library there is no chance
for the alternative tsp to hook itself into the process
of thread creation. Therefore, the storage used for
storing the data specific to a single thread is allocated
later, e.g. when .get() is called. Of course, this
can fail due to lack of memory. To make .get() nothrow
.get() would have to return 0 in that situation.
Now, I see, that this wasn't a good idea in the first
place. (The alternative tsp's) .get() should be able to
throw bad_alloc and ->() and *() should assert .get().

>                                Oder? You might want to 
> take a look at:
> 
> <http://tinyurl.com/uj61> -> <http://tinyurl.com/uj5x> 

Thanks for these pointers. I'll probably need some time
to understand how this is related to Boost's existing
thread specific pointer (which doesn't allow for custom
deleters) or the current idea (which isn't planned to
allow for custom deleters, atm)

FWIW, boost::thread_specific_ptr does not delete any
thread's specific storage upon destruction. That is
also the policy I wanted for the alternative tsp (which
I don't see as a replacement for the existing tsp
implementation.)

Regards,
m