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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-27 10:33:31

From: John Max Skaller <skaller_at_[hidden]>
> 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.

It's not impossible, as I posted a solution already
using ref-counting.  Windows provides a DuplicateHandle
function that would also work, unless the thread object
needed more data than just the handle.

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

Yes, so far as it goes.

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

My concern is that some common idioms would require wrappers
that could be done more efficiently in terms of the underlying
APIs.  That is, I might need to reference count handles that
are already reference counted by the OS, and might need to
arrange to catch exceptions, decrement counters, and close
handles in the thread function, this duplicating some of
what our library-provided function has to do anyway.

So the design I like is a thread class (or namespace) that
provides a few static functions like create(), sleep(), and
yield(), and a thread_ref class with copy semantics that
provides alive() and join().

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

Uugh.