Re: Killing a MMTimer
Keep in mind that the best way to stop function execution is not to call it
In multithreaded programming, if you have a possibility that your timer
fires at the moment when you about to decide you don't want it, you can't to
anything about it. If you cancel the timer before it fires, it won't be
called; if you try to cancel it after it fires, then you're out of luck;
there is no bulletproof solution for that.
The best way to deal with your problem is to serialize your timer with your
message handling. This means use regular Windows timer (SetTimer) which will
be executed in your GUI thread. This way, you won't have to make a decision
half way your timer executes.
"clinisbut" <email@example.com> wrote in message
Why, what do you think this would give you? If you know at that point
that you want to kill the timer just don't call the send data
The problem is if send_data starts to execute and then I detect that I
don't want to send_data, that's the problem.
I'll try to explain more detailed.
I have a thread that is reading from a serial port, and every time it
reads something from serial sends a message to GUI thread.
This message is pooled, and when I execute its function callback I
disable the timer. The timer has the job to send again the last frame
in case no answer received.
If the reader thread sends a message to GUI thread, and meanwhile
other messages are being processed the timer fires up, I need to
cancel this timer. That's why I think in sending another message from
the timer, so it goes to last position in pool and I can analyze the
bytes received first and decide if I wanna cancel the Timer.
But this doesn't solve the situation on the Timer sending first than
Reader Thread message.
The device which I'am communicating is very fast, but for some reason,
with a buffer length > 1 sometimes (very sometimes) the message
reader throws takes too long to be processed and until that, the timer