Re: [boost] Re: Boost.Threads - thread_desc concept

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-06-27 10:11:46

Greg Colvin wrote:

> I think I like it, but I'm not seeing an easy way to
> create a thread object that goes away when the thread
> exits.

        That's just as (im)possible as a Window object
that goes away when the window it represents dies.

        There is a solution, which is that the object
is only seen by the thread/window itself (and the object
suicides as required).

        Otherwise, you end up blocking in the destructor.
I think that this is feasible, I've seen it done
in coroutine and thread classes before.

        I think the question is: does the bare bones
solution _prevent_ wrapping up a thread_manager object
with these semantics?

        I think it is important _not_ to pre-empt the users
favourite technique for handling threads: that's why I think
the basic design is probably right (rather than the handle
design).

        Consider a solution which blocked in the destructor.
How would that coexist with a garbage collector?? 
The way I see it, the basic design should:

        1) set up parameters in the constructor,
        but NOT start the thread

        2) use a method for each operation

        3) provide a 'wait on death' method

        4) do nothing in the destructor except
        let go of the thread

This allows a thread-manager object to wrap the class
and

        1) start up on construction
        2) block in the destructor

For example. [important: only one example of what a user might want]

It also allows deriving new classes from BOTH the thread
and thread-manager objects, independently.

To put it another way, a lightweight wrapper which covers
existing APIs and doesn't try to do much work can't be wrong:
all it does is provide a common interface to conforming APIs.

It may not do everything one wants. But as long as it doesn't
stop you doing what you want, it has achieved a single
vital goal: platform independence.

And we can move on, and have a go at one or more management
schemes, aimed at a higher level of usage, without
alienating people that don't like any of the solutions.

Just pretend you're a committee :-)

-- 
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  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net