Prev: Problem with blocking of main thread with other thread
Next: CFtpConnection::PutFile and ProgressBarCtrl
From: Josh McFarlane on 14 Jul 2005 16:03
I've got the ever so fun job of working with a 3rd-party API that has
the ability to not return until new data is acquired.

I have instances of a thread that call this API function, and can end
up hung on that execution. During the shutdown process for the
application, and / or recovery, I need to terminate these threads, and
if they did not terminate through the normal shutdown procedure (done
via polling and returning 0) I need to clean up the remaining memory.

So far all the termation functions I've found require calling within
the running thread. In my case, as the thread is locked, this is not
possible. Is there a way to force the thread to terminate?

For example, if I have the CWinThread object stored, I want to be able
to do:
WaitForSingleObject(Threads.ConsumerList[i]->m_hThread, 6000); //Wait
for it to close. Timeout is one minute.

and then switch the result to force the thread to stop if not
terminated within the minute.

Thanks,
Josh McFarlane

From: Scot T Brennecke on 14 Jul 2005 16:38
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.

"Josh McFarlane" <darsant(a)gmail.com> wrote in message
news:1121371405.036575.203400(a)g49g2000cwa.googlegroups.com...
> I've got the ever so fun job of working with a 3rd-party API that has
> the ability to not return until new data is acquired.
>
> I have instances of a thread that call this API function, and can end
> up hung on that execution. During the shutdown process for the
> application, and / or recovery, I need to terminate these threads, and
> if they did not terminate through the normal shutdown procedure (done
> via polling and returning 0) I need to clean up the remaining memory.
>
> So far all the termation functions I've found require calling within
> the running thread. In my case, as the thread is locked, this is not
> possible. Is there a way to force the thread to terminate?
>
> For example, if I have the CWinThread object stored, I want to be able
> to do:
> WaitForSingleObject(Threads.ConsumerList[i]->m_hThread, 6000); //Wait
> for it to close. Timeout is one minute.
>
> and then switch the result to force the thread to stop if not
> terminated within the minute.
>
> Thanks,
> Josh McFarlane
>


From: Doug Harrison [MVP] on 14 Jul 2005 16:51
On 14 Jul 2005 13:03:25 -0700, Josh McFarlane wrote:

> I've got the ever so fun job of working with a 3rd-party API that has
> the ability to not return until new data is acquired.
>
> I have instances of a thread that call this API function, and can end
> up hung on that execution. During the shutdown process for the
> application, and / or recovery, I need to terminate these threads, and
> if they did not terminate through the normal shutdown procedure (done
> via polling and returning 0) I need to clean up the remaining memory.

The OS will reclaim "ordinary" memory, e.g. that obtained from CRT
functions, VirtualAlloc, HeapAlloc, etc.

> So far all the termation functions I've found require calling within
> the running thread. In my case, as the thread is locked, this is not
> possible. Is there a way to force the thread to terminate?
>
> For example, if I have the CWinThread object stored, I want to be able
> to do:
> WaitForSingleObject(Threads.ConsumerList[i]->m_hThread, 6000); //Wait
> for it to close. Timeout is one minute.
>
> and then switch the result to force the thread to stop if not
> terminated within the minute.

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++
From: WTH on 14 Jul 2005 20:40

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


From: Mihajlo Cvetanovi? on 15 Jul 2005 04:30
Josh McFarlane wrote:
> I have instances of a thread that call this API function, and can end
> up hung on that execution. During the shutdown process for the
> application, and / or recovery, I need to terminate these threads, and
> if they did not terminate through the normal shutdown procedure (done
> via polling and returning 0) I need to clean up the remaining memory.
>
> So far all the termation functions I've found require calling within
> the running thread. In my case, as the thread is locked, this is not
> possible. Is there a way to force the thread to terminate?

If you want to terminate threads only when process should finish then
you don't have to do anything special, just exit from process and the
locked threads will terminate along the way.

If you want to terminate the locked thread but keep the process alive
then you could consider creating a new process. It is more expensive
than creating a thread (both for coding and executing), but even if you
TerminateProcess there wouldn't be side effects to your code.

Of course, you could always disassemble the library and fix the bug ;-)
 |  Next  |  Last
Pages: 1 2
Prev: Problem with blocking of main thread with other thread
Next: CFtpConnection::PutFile and ProgressBarCtrl