Killing a Thread in Windows?

I have a database app that is blazing fast in OS X but when loading data into a listbox from large tables in Windows it is so slow as to be essentially useless. I’m using a thread to process table data and a timer to update the UI while the thread is running so that the progress bar will work. I also have a cancel button that will kill the thread and disable the timer if the user gets tired of waiting for a long process to complete. It works as expected in OS X but if a thread is killed in Windows, Windows reports the app is not responding and it has to be manually closed. I’ve tried catching ThreadEndException errors but that doesn’t solve the problem. Is there an effective way to kill a thread in Windows without the OS thinking the app has crashed?

Killing thread is a bad idea. Better set a cancel flag and check that in the thread so you end thread nice.

Are you talking about simply jumping to the end of the thread if the cancel flag is true? Otherwise, the only way to interrupt a running thread is to Kill, Suspend or Sleep it.

Well, I just answered my own question. Placing this at the end of a For/Next loop works:

If CancelFlag = True then Return End if

Thread.Kill absolutely should work. If you find that it’s causing problems, please file a bug report. Right now, only example I have requires a plugin to reproduce.

Killing a running thread in Windows does appear to hang the app and cause the OS to respond to the app as if it has crashed. I need to test it a bit with this alternative method first to verify that Thread.Kill is actually the culprit.

I have confirmed that using a cancel flag as suggested by Christian Schmitz to interrupt a running thread solves the problem, so it looks like killing a thread in Windows does cause the OS to catch what it thinks is a crashed application. I will have to create a sample project for a feedback report as my production project is too big to submit for that purpose.

I’m having the same problem (among others) with Threads in Windows.
Killing a thread sometimes cause a crash with a Memory Access Violation.
Also, running again a thread which is in NotRunning state, it hogs the CPU and nothing else get time to be executed. I’ve found that to avoid this problem I have first to destroy the Thread and then initialize it again and run.
Additionally, threads in Windows are very rough. I often have to sleep the tread for 100ms or more to have the UI responsive. And this with a lowest priority possible thread.

Something is bad with Threads on Windows, the problem is I can’t replicate the bugs.
I tried to build an example project for a bug reports which contains a stripped down version of my code, but can’t reproduce the problems.
This remember me some other situation I found where memory corruption occurs for same reason. And this is not always easy to reproduce.

And all this works properly with Cocoa.

We’ve had the same issue with killing threads crashing in Windows and other inconsistencies, so we’ve come up with the following setup that seems to work successfully on Windows and in Carbon/Cocoa. Basically it’s a method that will kill the thread in its own way on Mac or PC, and then either exit and call itself (on Mac, since this has been necessary in our experience), or continue on Windows.

The thread myThread is stored as property within the window/app somewhere.

[code] sub LoadItems()

//Windows thread kill code
if TargetWin32 then
    if myThread<>nil and myThread.State=thread.Running) then
        myThread=nil
    end if
end if

//Setup thread if it doesn't exist
if myThread=nil then
    myThread=new myThreadClass
    myThread.Priority=thread.LowestPriority
end if

//Mac thread kill code
if myThread.State=thread.Running then
    myThread.Kill
    LoadItems
    Return
end if

myThread.run

end sub[/code]

It’s not pretty, but it’s the only way we have been able to on Mac and Windows load information with a thread that may occasionally need to be killed or restarted.

I have to agree with Christian Schmitz’s answer.

I use tons of complex threads in my own apps, which runs smooth on Win/Linux and MAC without any of these problems.

But I guess it’s due to the fact that I am always doing it exactly as Christian suggested; Instead of brute-force killing threads, I always add a “QuitThread = TRUE” flag which the thread’s main-loop checks for to see if they should instantly quit before they are finished.

[quote=34786:@Thomas H]I have to agree with Christian Schmitz’s answer.

I use tons of complex threads in my own apps, which runs smooth on Win/Linux and MAC without any of these problems.

But I guess it’s due to the fact that I am always doing it exactly as Christian suggested; Instead of brute-force killing threads, I always add a “QuitThread = TRUE” flag which the thread’s main-loop checks for to see if they should instantly quit before they are finished.[/quote]

That could work, but the problem is if you have more than one loop or a more complicated thread, you’ll have to put checks for the quitFlag all over the thread. And even when doing that, we’ve had issues with crashes occurring on Windows, as there is no surefire way to quickly start the thread back up.

Really, what’s the point of having a thread.Kill method if it’s not supposed to be used? Either way, it seems on Windows setting the thread to nil is a dirty way of doing a thread.Kill without freezing the app.