Chris Coleman wrote:
Hi Ben, and others.
Many thanks for taking the time to reply to the original questions, they have proved most useful in providing me with a solution to my problem.
Depending on why and how the thread is sleeping, it may be possible to interrupt such a sleep by sending the thread a signal or writing to a pipe.
I'm still a little confused by this last sentence.
Under Unix, signals generally interrupt system calls, and you can configure whether the calls will be restarted or whether they will fail with an error code of EINTR (using setsigaction, if I remember correctly). What I don't know is whether Boost's condition variable implementation will restart the wait if it gets EINTR; it might be worth checking the source. I mentioned pipes because if the thread normally waits using select() you can create a pipe to be included in the read set and interrupt the wait at any time by writing an arbitrary byte to that.
At present I have opted for an arbitrary time on a timed wait on the condition variable that was causing the threads to sleep. This seems to work, but obviously there is a delay in the time the thread takes to die of up to the length of the timed wait. All the threads are waiting on the same condition variable, I can find nothing in the Docs about anything else that will cause the threads to wake while waiting on a condition variable.
Notify_one is no good since it is unspecified which thread shall be woken, and notify_all seems a little excessive when only a specific thread needs waking. Although I guess once woken all the other threads will do will be to see that their living flag is still true, and that there are no tasks to process and as such go back to sleep. Whatever solution is chosen it needs to be highly portable.
If all the threads are doing the same thing, does it matter which one you instruct to terminate? Perhaps you could just put a "stop" message on the work queue and use notify_one. Ben.