Ok, so I am writing my first "real" threaded application.

I have come to the point where I want to cancel the thread but I want to do it nicely.

So my plan was to join it, waiting for it to quit on its own. But what if the function is running an infinite loop? Is there a way I can say like "you got 5 seconds to die or I am killing you"?

Or any other ideas on how to destroy a thread in a nice way? All tutorials I've read on pthreads just say "think twice on how you cancel your threads" but none give any examples on how to do it. :P

What you should do is to signal the thread in some way that it should now please terminate itself.

For example, set a global boolean that says to the thread-world, "okay, folks, game over." Then, signal all the condition-variables that the respective threads are waiting on. They should all, in their turn, notice that the game-over flag is set, and proceed in an orderly fashion to put their houses in order and die.

If your threads naturally do things that might "run too long," then you should already have some kind of signal-mechanism in place that can be used to asynchronously notify them of the referee's-whistle. (Presumably you would use this for any sort of request. Such a signal, by itself, does not "cause the thread to die.") So you might do all three things:

1. First, set the game-over flag.
2. Then, signal everyone's condition-variables so if they're sleeping now they'll wake up.
3. Finally, if necessary, send a user-signal to the threads in case they might be busy, but be sure that the threads know to ignore that signal (or at least do-nothing) when they are in the process of closing down. The signal must be "absorbed," quietly.

The strategy here is that threads handle their termination in exactly the same fashion that they handle any other sort of request: it's not handled like any sort of exception. The thread simply stops accepting new requests, releases its resources, and dies.

"Termination time" is always the second-bumpiest moment in a program's life. There's a great potential for timing-holes at that point, and your design here must be careful and thorough.

The thread should issue a trap command or the equivalent higher level language function call:

http://linux.die.net/man/1/trap

The parent routine should issue a kill:

kill SIGTERM pid

http://learnlinux.tsf.org.za/courses...g/ch12s03.html


--------------------------
Steve Stites

Yeap, that's what I am doing right now. It works, but it takes a while to quit if the thread is running a sleep(10) :P

Problem here is that the whole reason I am using threads is so I can put all my third-party plugins in their own threads. So therefore I am not in control of the actual code that the thread is running.

So my solution would be to first of all provide the plugin writers with the class method
bool isRunning()
where they could check whether I want them to run or not.

However, let's say that we have a really bad developer writing a plugin which does not care about my bool, it just continues to run, or it may be inside a sleep(100) or something.

I still have control of the class that the plugin inherits. So I figured that I could use that class to send thread signals (since I do not want to make the plugins too complex to write, the developers should not have to worry about threads, they should not even know about them).

What is the bumpiest? :P

Thanks, I will read about that and see how I can use it.