Re: [boost] Boost.Threads, N2178, N2184, et al

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2007-03-26 16:31:28

Howard Hinnant wrote:
> Good question.  It is part of the pthreads model and has been  
> requested a lot from clients of boost::thread.  It arguably (and I  
> didn't realize this at first) provides the needed semantics of  
> ~thread():

"needed" depends on what a thread (object) really is. Is it an
identifier which is needed when I want to establish a communication
channel to the thread, or _is_ it _the_ thread. The latter sounds
debatable for me.

Let me try to put an (somewhat stretched) analogy:

struct A {
   int* p;
};

A* aA = new A;
aA->p = new int;

Now when I call delete aA, I have a memory leak.
Similar when ~thread() without taking care the thread has been
shut down.

> I.e. if the parent thread leaves the room unexpectedly, what do you  
> want to happen to the child thread?  boost::thread simply detaches.   

And this looks reasonable to me at this level.
A parent child relationship could be externally superimposed if needed.

Also not necessarily the thread would need to loose its id when
~thread(). Al though not possible with boost::thread you could re-attach
to the thread later if you know its id. (It's still there.)
boost::thread with it's noncopyable semantics currently _is_ more or
less such an id.
(You are not freeing an address when calling delete, you are freeing
the pointed to memory block. But of course we are free to give
~thread() whichever semantics seems reasonable.)

What I really meant by "do we need cancellation" is the inherent
meaning of cancellation: once started you can't stop it.
Your example seems to imply this, but I don't think this
necessarily is the case.

Another point (not a strict technical one though): Developing a
mechanism that could be used for cancellation but strictly speaking
_is_ _not_ cancellation could end the stalling discussions about
cancellation, which are lasting almost forever now.

I remember some similar threads about the very same topic years ago
when I discovered boost. I am very afraid that we are about to
repeat history here.

Having said this, by no means I think we should "cancel" ;-) this
discussion (thread), I just want to say perhaps we should consider if
"throwing an exception" at it could lead us to a more promising route.

Roland