Prev: Problem with blocking of main thread with other thread
Next: CFtpConnection::PutFile and ProgressBarCtrl
From: WTH on 15 Jul 2005 09:02
WTH <spamsucks(a)Ih8it.com> loquated like no one had ever loquated before
with:

> Scot T Brennecke <ScotB(a)MVPs.spamhater.org> loquated like no one had
> ever loquated before with:
>
>> There is always the TerminateThread API function in Win32. It has
>> inherent troublesome side-effects, of course, but when you must
>> absolutely, positively kill the thread, this'll do it.
>
> Indeed; however, be very aware that it was not de-allocate stack
> space.
> WTH

Errr... Will not de-allocate... ;)

WTH

--
"Life is only worth experiencing if you are prepared to go beyond the
edge." - Gýrard Houllier


From: Josh McFarlane on 15 Jul 2005 12:39
Doug Harrison [MVP] wrote:
> The OS will reclaim "ordinary" memory, e.g. that obtained from CRT
> functions, VirtualAlloc, HeapAlloc, etc.
The thread that I need to forcibly terminate allocates memory with new.
So will this automatically be released?

> My little threads FAQ discusses several things relevant to programming with
> CWinThread and asking threads to shut down:
>
> http://members.cox.net/doug_web/threads.htm
>
> However, it sounds like your threads are executing a blocking call, and
> they cannot proceed until it returns. You could adapt what I talked about
> by executing that function with a thread pool thread, such that the caller
> would end up waiting like this:
>
> // Pseudocode
> WaitForMultipleObjects(hQuitEvent, hFunctionCompleted);
>
> This way, your secondary thread can respond to you setting hQuitEvent and
> exit nicely, and only the thread executing the asynchronous function call
> would be terminated mercilessly with TerminateThread, which ultimately is
> what happens anyway to secondary threads when the primary thread calls
> ExitProcess. That said, I'd look for another way to force an early return
> from that function, as TerminateThread can have many undesirable
> side-effects.
>
> --
> Doug Harrison
> Microsoft MVP - Visual C++

The thread is part of a thread pool. Basically, there will be a debug
screen, and if one of the collection threads (one per device at the
moment), I'd like to be able to destroy the thread and restart a new
one for the pool. However, it will be hung on the actual collection
call to the 3rd party library, which will have had memory allocated for
it.

I have no real control over the function returning, unless I decide to
reverse engineer the library and driver code, which would be more time
than I'm willing to invest in it. The thread polls for shutdown each
time it collects data, and then adds that data to a queue to be handled
in another thread.

Since I can always assume that if it is not responding it will be stuck
on that specific line of code, if I can terminate the thread, I know to
delete one pointer and then deinitialize the capture device. However,
you guys say that there are undesirable side-effects. What could occur
from terminating the thread in the middle of running when I know which
line it is held on?

From: Doug Harrison [MVP] on 15 Jul 2005 16:07
On 15 Jul 2005 09:39:11 -0700, Josh McFarlane wrote:

> Doug Harrison [MVP] wrote:
>> The OS will reclaim "ordinary" memory, e.g. that obtained from CRT
>> functions, VirtualAlloc, HeapAlloc, etc.
> The thread that I need to forcibly terminate allocates memory with new.
> So will this automatically be released?

When the process terminates, yes.

> Since I can always assume that if it is not responding it will be stuck
> on that specific line of code, if I can terminate the thread, I know to
> delete one pointer and then deinitialize the capture device. However,
> you guys say that there are undesirable side-effects. What could occur
> from terminating the thread in the middle of running when I know which
> line it is held on?

It depends partly on what the function you called has done to that point.
The TerminateThread documentation talks about many things that can go
wrong. If using TerminateThread is to be a normal part of a long-running
program, you might consider the suggestion to offload the potentially
hanging function to another program, using some sort of IPC in a
client/server arrangement.

--
Doug Harrison
Microsoft MVP - Visual C++
First  |  Prev  | 
Pages: 1 2
Prev: Problem with blocking of main thread with other thread
Next: CFtpConnection::PutFile and ProgressBarCtrl