Re: Boost.Threads - Questions

From: williamkempf_at_[hidden]
Date: 2001-08-20 19:41:04

--- In boost_at_y..., John Max Skaller <skaller_at_m...> wrote:
> Peter Dimov wrote:
>  
> > [2] I have the following problem. I'm trying to create a non-
local thread
> > object:
> > 
> > shared_ptr<thread> p(new thread(f));
> > 
> > _but_ I also want to pass 'p' to the newly created thread. I 
don't see a
> > simple way to achieve this. In a two-phased construction design 
this is
> > trivial:
> > 
> > shared_ptr<thread> p(new thread); // creates a 'detached' thread 
object
> > p->create(bind(f, p)); // create the thread and associate it with 
*p
> > 
> > Of course two phased construction is evil.
> > 
> > The problem doesn't arise when I code directly to win32 or 
pthreads, which
> > means that it's (possibly) a defect in the design (minimal but not
> > complete.)
> > 
> > Opinions?
> 
> 	I think I agree. The usual 'hack' is to make sure that the
> thread function accepts a void*, and to pass the 'interlock' 
pointer in
> it.
> [Is there a name of a pair pointers that point at each other?]

I still don't see any deficiency in Boost.Threads where POSIX and 
Win32 don't in this case.

> 	Similar problems exists creating windows: you want
> the representation object to know the window handle,
> but you also need to be able to get the representation
> object directly from the window handle.
> 
> 	You can't do this with the old MS-Windows API,
> but you can with the client_data argument in X-Windows.
> Whole application frameworks were built around this
> deficiency of MS-Windows (Borland OWL for example).

*Ahem* Way off topic, but Win32 *DOES* provide the equivalent 
of "client_data", it's just too fragile of a mechanism for 
tying "Windows" to C++ class instances.
 
> 	[in the thread case -- I assumed you'd want to
> bind a child to its parent .. but that can already be done,
> since the thread function is actually a functiod.
> In the example above, it won't work, because it has to
> be initialised before it is passed, but can't be, 
> since the data it needs is created by the call that
> passes it.]

Which is the same issue that exists for POSIX and Win32 thread 
libraries.  Again, they get around it (if you need to do this) with 
the same sort of techniques available in Boost.Threads.

Bill Kempf