Re: [boost] [thread] thread interruption semantics

From: Preston A. Elder (prez_at_[hidden])
Date: 2007-11-14 08:07:30

On Wed, 14 Nov 2007 11:05:20 +0000, Anthony Williams wrote:

> Another option is to add the concept of a "interruption handle" (maybe
> as part of thread::id) which can interrupt a thread without allowing for
> other things like detach or join.

This is a better option, but the problem is, just as with doing a join, 
interrupting one's self does not make sense either.  In the end, all of 
these actions are things only another thread would execute on 'your' 
thread, however the problem is we need a method of telling the other 
thread "This is my thread, if you want to perform actions on me!".

Though the problem of having multiple references to the same thread * is 
a real one, if two threads did a pthread_join() you would have no end of 
pain.  So I guess this, at least, is safe to have multiple entities of, 
since the 'interruption context' should be lifetime managed by the thread 
itself, not by the existance of a thread * (which, after all, you can 
delete without killing the running thread).

But then, operator== and operator!= also should be managed by the life of 
the thread too.  But since these are legacy interfaces, I could live 
without that. 

PreZ :)