Discussion:
VC++ 6.0 hung class
(too old to reply)
Ed
2011-07-03 17:03:25 UTC
Permalink
I have a class function called from the main dialog that processes a
large amount of data.
If this class hangs, waiting for data it never receives, how do I abort
it from within the main dialog?
Maybe with an abort button on the main dialog?
But how do I implement it to return from the hung class?

Here is what I have in the main Dialog that calls the class in question

CRunU1 RunU1;

//the test button sends data (Top1 is a string of 8-bit chars)
//to the class for processing
void CMain1Dlg::OnTestbutton()
{
if(!RunU1.KeyData(Top1)){
c_Info.SetWindowText("Unable to Run...");
}
else{
c_Info.SetWindowText("Running..."); //I do get this message
}
}
Joseph M. Newcomer
2011-07-03 18:20:51 UTC
Permalink
See below..,,
Post by Ed
I have a class function called from the main dialog that processes a
large amount of data.
If this class hangs, waiting for data it never receives, how do I abort
it from within the main dialog?
****
First, you should NEVER even consider this as a possibility! Note also that a class does
not hang. Code can block indefinitely, but the class is mere syntactic decoration that
has little relevance at execution (the computer sees machine code, and only machine code,
and doesn't ask what it came from).

You could not "abort" a class any more than you can deep-fry one.
****
Post by Ed
Maybe with an abort button on the main dialog?
****
Your major failures here
- Allowing blocking I/O
- Allowing blocking I/O in the main GUI thread

Since you have not said where the data is coming from, there is no way to suggest the
correction for using asynchronous I/O, but if you are using CSocket, you are already in
such deep trouble there is no recovery. You need to recode it to use CAsyncSocket. There
is no other option. For other communication mechanisms, there are other solutions. Some
solutions are possible for Vista and WIndows 7 but not earlier, so it is important to know
the platform you will be running on.

If the main GUI thread is blocked, no button will EVER do anything. It cannot be clicked
because the main GUI thread is blocked. Therefore, you will not EVER block the main GUI
thread.

After that, the question cannot be answered unless there is considerably more detail about
the nature of the communication.
*****
Post by Ed
But how do I implement it to return from the hung class?
*****
Since a class cannot hang, the question has no answer. And the other answer is: if you
call code from the main GUI thread that can block indefinitely, your fundamental design is
flawed beyond redemption. Only a redesign and recoding can save you. You will put the
blocking I/O in a separate thread. Period. Unless it is socket communication, in which
case a CAsyncSocket *is* legitimage in the main GUI thread because it never blocks.
*****
Post by Ed
Here is what I have in the main Dialog that calls the class in question
CRunU1 RunU1;
*****
You do not call a class. Calling a class is similar to deep-frying one. The verb has no
meaning. You call methods of a class.
****
Post by Ed
//the test button sends data (Top1 is a string of 8-bit chars)
//to the class for processing
void CMain1Dlg::OnTestbutton()
{
if(!RunU1.KeyData(Top1)){
c_Info.SetWindowText("Unable to Run...");
****
OK, you seem to be waiting for keyboard input. That, of course, is inherently
asynchronous, and therefore you need to explain more why this is a potential problem. If
this is a console app, the whole notion is ridiculous. You would NEVER wait for keyboard
input in the main thread!

You have not said whether the string is being filled in by the function, or is being sent
by the function. If it is being filled in, this code is unacceptable and must be
rewritten. Also, you have not indicated where the variable lives; if it is a global
variable, this is bad programming, and if it is a member of the class, it is questionable
programming.

Also, the correct code would be
CString msg;
msg.LoadString(IDS_UNABLE_TO_RUN);
c_Info.SetWindowText(msg);

since it is (a) bad practice to use 8-bit characters in modern programs and (b)
unacceptable practice to use native-language string literals in modern programs

Bottom line: (a) don't use blocking I/O (b) if you must use blocking I/O, put it in a
separate thread.

You should read my essays on threading on my MVP Tips site.
****
Post by Ed
}
else{
c_Info.SetWindowText("Running..."); //I do get this message
****
Note that you will only get this message AFTER the running has completed! So it ISN'T
running, it has already finished!
joe
*****
Post by Ed
}
}
Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Loading...