Boost logo

Boost :

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-20 17:44:24

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
[Is there a name of a pair pointers that point at each other?]

        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).

        [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.]

John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix
Literate Programming tool Interscript

Boost list run by bdawes at, gregod at, cpdaniel at, john at