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
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
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk