Fw: Boost.Threads thread_specific_ptr and more

From: Philip Ashmore (philip_ashmore_at_[hidden])
Date: 2002-03-21 02:44:14

Oops! I didn't know I had to join the group!

Regards,
Philip Ashmore
----- Original Message -----
From: "Philip Ashmore" <philip_ashmore_at_[hidden]>
To: "William Kempf" <williamkempf_at_[hidden]>
Cc: <Boost-Users_at_[hidden]>
Sent: Wednesday, March 20, 2002 12:29 PM
Subject: Re: Boost.Threads thread_specific_ptr and more

> 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" <williamkempf_at_[hidden]>
> To: <philip_ashmore_at_[hidden]>
> Sent: Friday, March 15, 2002 3:13 PM
> Subject: Re: Boost.Threads thread_specific_ptr and more
>
>
> > >From: "Philip Ashmore" <philip_ashmore_at_[hidden]>
> > >To: <williamkempf_at_[hidden]>
> > >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
directly
> 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_at_[hidden]) 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
then
> 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
think?
> >
> > I think I need more explanation and possibly code examples.
> >
> > Bill Kempf
> > williamkempf_at_[hidden]
> >
> >
>

[Non-text portions of this message have been removed]