"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
Then you need to figure out how to abort a server-operation-in-progress.
The usual way to
do this is to use some kind of asynchronous connection and just close
the
connection.
In the case of an asynchronous connection, you usually DO use a UI
thread
(it is worth
pointing out that the phrase "time consuming operation here" does not
convey in any
meaningful way what is going on; the correct description would have been
"long-duration
synchronous blocking operation here", since it actually consumes NO time
while it is
blocked.
For asynchronous operations, there is usually some callback method; for
most networking
calls, the callback method is handled by posting messages to the message
pump. Given you
have overridden the Run method, you would be unable to handle these. So
the first
critical piece of advice is to remove the blocking operation entirely,
and
replace it by
an operation that provides asynchronous notifications upon completion.
Then simply close
the handle to that target if you want to. A typical means of
initiating
this would be to
start a UI thread, and in the InitInstance handler do
PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE); // check parameter order
gui->PostMessage(UWM_THREAD_READY);
where gui is some CWnd * pointer to a window in your main GUI thread,
and
UWM_THREAD_READY
is a user-defined message. The PeekMessage serves no useful purpose in
messaging, but
causes the thread's message queue to be created.
Upon receipt of the UWM_THREAD_READY message, you will then PostMessage
a
request to the
thread to start the transfer. This will open an asynchronous connection
and you will
respond in the fashion appropriate for the asynchronous connection. If
you want to shut
the thread down, you might PostThreadMessage(UWM_SHUT_YOURSELF_DOWN),
which would be a
user-defined message you create for purposes of telling the thread to
shut
down.
The problem here is that with the lock() calls and the Run() override,
you
are trying to
impose synchronous behavior on a fundamentally asynchronous,
event-driven
environment, and
that is always a losing strategy. Get rid of the locks (you almost
certainly don't need
them...there are better ways to deal with this), get rid of the
synchronous I/O, and you
will be far ahead of the game.
joe
*****
On Sun, 29 Jul 2007 16:37:29 -0700, "Tech" <support@t-v-e-r-s-o-f-t.com>
wrote:
Scott,
thank you for the suggestion. Time consuming operation is not loop
based.
Basically (// time consuming operation here)s is an WinHTTP call to a
server
script and it may take up to a minute to execute the script on a server.
It
is possible to timeout on an Http request function, but this is not what
I
want, I need to halt -> terminate thread immideately.
2-nd question : is presence AfxEndThread a bug ?
Thank you!
TECH
http://www.tversoft.com
"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:6KednSq3VoDJhjDbnZ2dnUVZ_sOrnZ2d@comcast.com...
Tech wrote:
Run Function in the thread derived class looks like:
extern CCriticalSection lock;
//======================
Run()
{
lock.Lock(INFINITE); // lock one thread
// time consuming operation here
lock.Unlock();
AfxEndThread(0,TRUE); // end thread
return 1;
}
I need to terminate this thread via user action while the operation
is
in
progress. There is no memory allocation, other threads, etc. in the (
//
time consuming operation here )
What would be the best way to do that? TerminateThread? then what do
I
do
about the lock?
You can use a bool or SetEvent to signal the thread to exit. It
should
detect the signal and then exit in the normal way. Something like
this...
// time consuming operation here
while (!bThreadExit)
{ ...one step or loop of operation
}
lock.Unlock();
return 1;
You should also get rid of AfxEndThread so the return statement can
perform normal stack allocation cleanup.
--
Scott McPhillips [MVP VC++]
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm