Fw: Boost.Threads thread_specific_ptr and more

21 Mar 2002

      ...
Hi there.
Rather than respond to your points directly, I've written a document
outlining my ideas on how static data could be managed more clearly. This
obviously relates to thread_specific_ptr as instances are global, hence
static, but is quite general and therefore hopefully more useful.
Regards,
Philip Ashmore.
----- Original Message -----
From: "William Kempf" 
To: 
Sent: Friday, March 15, 2002 3:13 PM
Subject: Re: Boost.Threads thread_specific_ptr and more
...
...
From: "Philip Ashmore" 
To: 
Subject: Boost.Threads thread_specific_ptr and more
Date: Fri, 15 Mar 2002 14:37:39 -0000
Hi there.
first of all, I'm assuming that it's appropriate to contact you
...
regarding some queries I have regarding the Boost.Threads
thread_specific_ptr<T>.
...
Yes, though if you'd send it to the Boost Users list on Yahoo Groups
(Boost-Users@yahoogroups.com) instead others could benefit from the answer
as well.
...
...
As it happens I developed something similar before I became aware of
Boost.Threads thread_specific_ptr<T>, but with the following extra
features
you might consider discussing or adding.
...
...
1. Automatic construction of new instances of T as needed when
dereferenced.
I considered this and rejected it, mostly because this behavior may be
surprising to users.  Another issue is that this would require T to be
default constructable, which will limit the usefulness at least somewhat.
...
2. Assignment to thread_specific_ptr<T> of a local variable of type T.
This is basically already there with reset() but an explicit template
class
could handle connection and disconnection, coping with exceptions.
Could you elaborate?  I'm not sure I understand why you think an
assignment operator would be better then reset().
...
3. An optional Structor class template argument. Here the Structor
would
know how to create and destroy instances of T, useful when T can be used
in
different contexts.
This sounds like an Allocator, and if it wasn't a standard Allocator
...
it could be used to eliminate one of the problems I referred to in (1),
but
beyond this I don't see any benefit.
...
...
4. Automatic cleanup of instances of T when the thread_specific_ptr<T>
goes out of scope. These would be useful when you aren't in control of the
thread creation or destruction.
...
To be portable, thread_specific_ptr<> must be used only to instantiate
global variables (or the equivalent static variants).  So, this one can't
be
done (or more specifically adds 0 benefit).
...
...
This relates to static instance management. As you may know, some
compilers (or maybe it's C++ itself) have problems if you have static
instances of classes that have non-trivial static data members. The idiom
of
clients and managers is one solution - manager lifetimes enclose client
lifetimes. I've implemented this and it works.
...
I'm not sure that I'm aware of the problem you're alluding to.  Can you
elaborate?
...
...
A more general idiom is a dependency tree, where wrapper objects
declare
their dependency explicitly and a functor tree is created that is
independent of the order of static construction (a map would work here).
This tree is traversed during start-up and shutdown (using a scoping
object)
to ensure correct instantiation and destruction.
...
Are you referring to issues with the order of construction/destruction
for
global data?  If you are, there is no universal solution to this problem
and
I'm not about to try and address it.
...
...
It takes over work that the compiler should do correctly but doesn't
(at
least not on Visual C++ 6.0 sp5).
...
...
This would effectively solve all
static-object-dependency-across-libraries issues in a portable way.
Maybe this merits a file of its own in Boost.Utility. What do you
Oops! I didn't know I had to join the group!

Regards,
Philip Ashmore
----- Original Message -----
From: "Philip Ashmore" 
To: "William Kempf" 
Cc: 
Sent: Wednesday, March 20, 2002 12:29 PM
Subject: Re: Boost.Threads thread_specific_ptr and more

directly
then
think?
...
...
I think I need more explanation and possibly code examples.
Bill Kempf
williamkempf@hotmail.com
[Non-text portions of this message have been removed]