
"Preston A. Elder" <prez@neuromancy.net> 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