ASYNC_ATTR_TIMER_TIME

Question

If I have an async timer and it's making callbacks to a function that stalls, if another thread were to check ASYNC_ATTR_TIMER_TIME would this async timer attribute value been seen as failing to increase?  I.e., with postponed callbacks queueing up (due to failure of the callback to return since it's stalled) does this attribute value continue to increase with enqueued callbacks, or does it stop increasing until a successful callback is made?
I.e., how do I determine if an async timer callback has stalled?  I can't easily check on the async timer thread, since it belongs to the OS or the CVI runtime it would seem.  Maybe the first time the callback runs it gets the thread handle and then a second thread can use the handle to check on the thread.
I have an async timer callback that's stuck in an endless loop, inside the CVI serial library somewhere I think.  I'm doing an OpenComConfig on a virtual serial port (implemented in a DALSA framegrabber/DALSA DLL) within the callback, and it looks like it is getting locked up and not returning.  One of the CPU cores shows 100% utilization, I can't tell which thread is in it but I have good reason to belive it's the async timer callback - the process's CPU time shows full utilization.  I've had nothing but trouble using the CVI serial library with the DALSA virtual com ports - can't tell where the problem is, in the serial library or in the virtual com port.  I've eliminated com callbacks, I've output byte by byte with delays in between, increased timeouts, etc. etc.   Seems sensitive to queue sizes, timeout values, whether any UART lines were set ... it's been a real pain.
Thanks.

Answer 1

Hi menchar,
Let me just expand a bit on what Renée has said.
As you know, oftentimes, several of us CVI developers answer questions here in the forum whenever we know the answer right away. Even when we don't know the answer, if we're not too busy at the time, we'll run some tests or "look under the hood" to find out what the answer is and then answer it.
However, there are also lots of times when we don't know the answer right away. Even though, as you correctly pointed out, we might have implemented the feature ourselves, that might have been 10-15 years ago, and we simply just don't remember all the details any more. Or, in some case, the feature was implemented by someone who is no longer available to answer questions. We might have an inclination of what the answer might be, but it's probably not the best idea to tell you something that you then are going to rely on, unless we're pretty sure of it.
What Renée is trying to say is that, oftentimes, in order to find out what you want to know, any one will have to run the same exact test that you yourself can do.
From your point of view, I completely understand why you would ask questions here. There's a pretty good chance that someone might already know the answer. I definitely don't want to discourage you from continuing to ask these questions. That's what the forum is for. But I just want you to know that, if you don't get the precise answer that you're looking for right away, it's probably because no one really knew the answer right away. It happens.
Luis