Re: Problem writing Time-Out function
From: Joseph M. Newcomer (newcomer_at_flounder.com)
Date: 02/16/04
- Next message: Joseph M. Newcomer: "Re: TextToSpeech in MFC application"
- Previous message: Joseph M. Newcomer: "Re: Dynamic change of dialog controls' properties"
- In reply to: Arlis Rose: "Problem writing Time-Out function"
- Next in thread: Arlis Rose: "Re: Problem writing Time-Out function"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 16 Feb 2004 18:21:38 -0500
The problem is that the timer will not fire until you get back to the main message pump,
which you won't do because the library blocks (it may or may not be in an "infinite
loop"). So this solution cannot work. Because the GUI thread is blocked, or possibly
looping, you will be unable to shut the application down or notify the user.
This is a really nasty problem. The best solution is to create a thread that calls the
library, and then wait for it to terminate. There are two ways to do this:
WaitForSingleObject on the thread handle with a timeout, which blocks the GUI thread, and
having the thread PostMessage a completion notification to your GUI thread and simply
return, having done a SetTimer. While the GUI is in a state of "waiting for thread", you
have to disable whatever commands, menu items, etc. that would cause problems if activated
during this time. But it would allow you to pop up a "Cancel" dialog so the user could
cancel the operation earlier if desired.
Now the nasty part: there is no good, accepted, reliable way to kill that thread. The only
option available at this point is to call TerminateThread, which can lead to serious
problems later (particularly if the library is an ActiveX control or some other control
which leaves bogus state around such that another incarnation of the control will
malfunction in a different way. It is impossible to predict or control what will go wrong.
Maybe nothing. Maybe nothing on your machine. Maybe nothing this week. Maybe nothing with
this release of the library. And then again, you might get into a situation that causes
serious problems. You won't be able to tell what will happen. Or control it. Or recover
from it.
It would have been nice if the implementor of the library was prepared to deal with the
failure mode you describe, which should have been an expected failure mode. Alas, you are
not that fortunate.
When you have to deal with poorly-designed software like the library you are describing,
the ability to recover by doing "unapproved" things like TerminateThread will place you in
constant hazard. Essentially, the library is what we call Broken By Design, and you can
only hope that whatever approach you take will create a survivable situation. But there
are no guarantees in cases like this.
joe
On Mon, 16 Feb 2004 11:02:52 -0500, "Arlis Rose" <arlisATendevouraerospace.com> wrote:
>Alright this one might seem a little odd. Basically when I initialize my
>dialog I have to call a routine (RunSameThread) which unfortunately calls
>some functions set with a library (which I don't have the source code for)
>which may not exit. (Basically this call should initialize the COM port and
>send's some commands to a transceiver attached to the port, then wait for a
>response before returning). Now, if the transceiver is not hooked up (or
>turned on) the COM port initialization will go though, but the library
>function will sit in an infinite loop :(
>Thus, I am trying to write a time-out function such that if so many seconds
>go by and this function does not exit, I am going to shut the program down
>and notify the user.
>
>Here is how I am trying to do the above:
>in my OnInitDialog I have:
>SetTimer(IDT_TIMER_1, 4000, NULL);
>if (!RunSameThread) {
> AfxMessageBox("Could not initialize COM port");
> exit(0); //I do intend to put proper exit code here once I get the
>above working :)
>}
>KillTimer(IDT_TIMER_1);
>
>Then in my OnTimer() function I have
>
>if (TimerVal==IDT_TIMER_1) {
> KillTIMER(IDT_TIMER_1);
> AfxMessageBox("Timed out waiting for sat response!");
> exit(0);
>}
>
>Logically I thought this would work as the timer is set up before I enter
>the method RunSameThread(), and (using breakpoints) I know that the program
>never gets past the line if (!RunSameThread) { if the
>satellite/transceiver is not connected. Can anyone tell me first what I am
>doing wrong (is it perhaps the case that the this timer will only fire if
>the program is idle???). And if someones knows of a better solution that
>would work, could you please point me in the right direction (please just
>remember that I cannot edit RunSameThread to fix this solution as it calls
>functions which are in a compiled library (or dll I can't actually remember)
>but that source code was proprietory? so we are forced to work around it :(
>Thanks for your help!
>
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
- Next message: Joseph M. Newcomer: "Re: TextToSpeech in MFC application"
- Previous message: Joseph M. Newcomer: "Re: Dynamic change of dialog controls' properties"
- In reply to: Arlis Rose: "Problem writing Time-Out function"
- Next in thread: Arlis Rose: "Re: Problem writing Time-Out function"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|