Date: 2001-08-20 19:41:04
--- In boost_at_y..., John Max Skaller <skaller_at_m...> wrote:
> Peter Dimov wrote:
> >  I have the following problem. I'm trying to create a non-
> > 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
> > trivial:
> > shared_ptr<thread> p(new thread); // creates a 'detached' thread
> > p->create(bind(f, p)); // create the thread and associate it with
> > Of course two phased construction is evil.
> > The problem doesn't arise when I code directly to win32 or
> > 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'
> [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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk