Boost logo

Boost :

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 Williams
Just Software Solutions Ltd -
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

Boost list run by bdawes at, gregod at, cpdaniel at, john at