Re: [boost] [thread] thread interruption semantics

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-11-14 06:05:20

"Preston A. Elder" <prez_at_[hidden]> writes:

> The new interruption syntax promises to make this even easier - for all I 
> have to do is now store the thread pointer in the message when 
> interruptable, and then when I call message->interrupt() it calls
> thread->interrupt() and has the same effect as the interruptable_pred.
>
> The problem is, the tasks need to be able to give the CORRECT thread 
> pointer to the message.  But they can't.  Because they did not create the 
> thread, they don't have the thread *, and all I can really do from within 
> a thread is call this_thread::get_id() - which, while useful, does not 
> help in this circumstance.
>
> I can probably work around this whole mess (maybe using a thread-specific 
> pointer to store the thread pointer, since I do have control over who 
> DOES spawn the thread, this IS possible, however annoying ;P).  But the 
> fact a thread cannot more or less look up its own thread for the purpose 
> of telling another thread "If you want to interrupt me, use THIS handle" 
> makes writing this kind of functionality difficult, and if I did not have 
> control over who creates the threads - impossible.
>
> So, is it possible to get this fixed? :)

The Windows implementation has thread::self() which returns a thread object
referring to the current thread. However, I'm a bit concerned about this
because it means there are now two thread objects referring to the same
thread, so I haven't added it to the POSIX implementation yet.

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.

Anthony
-- 
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL