Author's Note. When I originally wrote this post, I described a technique by which a thread forcibly terminated itself by calling the TerminateThread function of the Windows API. Part of my goal was to share a technique that I haven't seen described before, which also made me somewhat suspicious that the technique might be wrong minded.
Though the code seemed to work alright, I invited comments from readers if they knew otherwise. The first comments to this post stated very clearly that this technique is not an acceptable one. In short, unless there is a very good reason (and there are few of those), you should not call the TerminateThread function.
Still, the original concept, that of a self-terminating thread, is an attractive one. However, instead of forcibly terminating a thread, the code presented in this updated post simply attempts to terminate the thread through its normal mechanism, by calling the thread's Terminate method. While this might not terminate the thread quickly (or ever if it is truly deadlocked), there is much less of a downside compared to the use of TerminateThread.
I considered removing this post. On the other hand, I think the comments are very good, well considered, and educational. In addition, I have modified the code presented here to remove the potentially harmful call to TerminateThread, and replaced it with a less forceful, yet still useful alternative. The following is the modified posting.
What can you do when a thread becomes unresponsive? Better yet, how can you create an instance of Delphi's TThread class that terminates itself if it becomes unreasonably slow?
This is the question that I had to address recently. In short, I was creating a Delphi application that used an Internet Direct (Indy) TIdTcpClient to make calls to a RESTful Web service. In doing this, I considered the sage advise of my friend and fellow Delphi Developer Days presenter Marco Cantù.
Marco is fond of pointing out that you should make remote calls to Web services or other Internet resources from a thread, permitting your user interface to remain responsive even if the service to which you are communicating becomes slow or worse.
There is a problem, however. Terminating a thread by killing it outright is serious business, and can easily lead to memory leaks and other similarly nasty side effects. For example, resources that your thread has allocated may end up abandoned upon the termination of the thread. And, as pointed out in some of the comments to the original post, can go so far as to undermine your entire process.
Since my original issue was associated with communicating with a RESTful Web service using a connection object (an Indy socket client in this case), I reflected on the technique I've used in JavaScript to make asynchronous calls to the same service. In that code I created a timer that was canceled once the XMLHttpRequest object (XHR) callback triggered. If the timer expired before the asynchronous request returned, the timer canceled the request. On the other hand, if the callback was executed, the timer was canceled.
So, here for your consideration is a simple TThread descendant that calls its own Terminate method (from the primary thread of execution) if it does not terminate on its own after a specified timeout. I follow this unit with some observations and final comments.
unit TimeoutThreadu;
// No guarantees or warranties are expressed or implied concerning
// the applicability of techniques or code included in this example.
// If you wish to use techniques or code included in this example,
// it is your responsibility to test and certify any code or
// techniques design adopted as a result of this project.
interface
uses
Classes, Windows, ExtCtrls, SysUtils, SyncObjs;
type
TTimeoutThread = class(TThread)
strict private
{ Private declarations }
FTimer: TTimer;
FTimeout: Boolean;
procedure OnTimer(Sender: TObject);
protected
procedure Execute; override;
public
constructor Create(CreateSuspended: Boolean;
Timeout: Integer); overload;
destructor Destroy; override;
end;
implementation
uses mainformu;
{ TTimeoutThread }
constructor TTimeoutThread.Create(
CreateSuspended: Boolean; Timeout: Integer);
begin
FTimer := TTimer.Create(nil);
FTimer.Interval := timeout;
FTimer.OnTimer := OnTimer;
Self.FreeOnTerminate := True;
FTimeout := True;
Self.Create(CreateSuspended);
end;
destructor TTimeoutThread.Destroy;
begin
//Note that a destructor is called even if
//an exception is raised in the constructor.
//That is why FTimeout is set to True after
//the thread's resources have been created.
if FTimeout then
begin
FTimer.Enabled := False;
FTimer.Free;
end;
inherited;
end;
procedure TTimeoutThread.Execute;
begin
if FTimeout then
FTimer.Enabled := True;
while True do
begin
//Your thread's code goes here
//Simulate work
sleep(2000);
if Self.Terminated then exit;
end;
end;
procedure TTimeoutThread.OnTimer(Sender: TObject);
begin
//This code executes in the primary
//thread of execution. As a result, it will
//execute even if the thread is currently blocked.
//Note, however, if the thread is blocked, it will
//not actually terminate until it is no longer blocked.
//Furthermore, calling a thread's Terminate method does
//not actually terminate the thread. It only set the thread's
//Terminated property to True. If your thread is designed
//to run continuously until it detects its termination,
//it is the responsibility of the code in the Execute method
//to test the Terminated property, and to exit gracefully
//once it finds that Terminated has been set to True.
FTimer.Enabled := False;
Self.Terminate;
end;
end.
This thread can be created as a self-terminating thread using code as simple as the following:
with TTimeoutThread.Create(True, 10000) do Start; //call Resume with Delphi 2007 or earlier
To begin with, this thread can be run without or without a timeout. If you call the inherited constructor, it does not timeout.
When you call the overloaded constructor, you pass the timeout, in milliseconds, in the second parameter. In that case, the first statement in the Execute method (the one method of the thread that runs in a worker thread) initiates the Timer.
If the thread terminates normally, and it was created with a timeout, it terminates the timer. And, if the timer expires at about the same time as the thread is terminating, there is no harm. Calling Terminate on a terminated thread is not a problem, and setting a timer's Enabled property to False when it is already set to False is likewise not a problem.
But permit me to mention a limitation. This thread is freed on termination. If you need a thread to stick around after it has terminated, this one is not for you. On the other hand, you can create an OnTerminate event handler, and persist any information that the thread has collected from there.
Once again, this post has been modified. The original code included a call to the Windows API function TerminateThread from within a synchronized block of code in the OnTimer event handler. I asked for input regarding this approach, and the response was universal: it was the wrong thing to do. Please enjoy the thoughtful comments submitted by readers.
