postdeferredcall speed

[crazyfwed]

Hello,

I'm using PostDeferredCall to schedule a call to a function very often, and if I don't move the mouse I have some calls per seconds, but if I move the mouse (while over any panel) I can have tens of calls per seconds.
Is it something usual ? Is there a way to control this behavior ?
I don't have any problems because of that but I'm wondering if I can more or less "predict" the call rate.
Note that my software is in "debug configuration" and I have not tried "release configuration", and I'm using CVI 8.5.

Kind regards.

[JonathanN]

Hi crazyfwed,

Without looking into the source directly I can only provide you with a theoretical reason as to the behavior you are seeing.  Hopefully this answer will satisfy your curiosity.

Essentially PostDeferredCall tells CVI to call a specific function the next time CVI processes events. Now it’s important to understand that we try to be "smart" in terms of how often pump messages.  By that I mean in certain parts of our message pump code, we make calls into the Win32 Sleep() function.  How often we call Sleep or when we call Sleep is dependent upon what you have set as your sleep policy.  When I said we are being "smart", I meant that if for example, we see that system events are being fired, we will go ahead and start pumping messages.  Since the call to PostDeferredCall is on the queue, we will go ahead and address that call (i.e. by calling the function you specified).

Now the reason I stated that is because I believe what is happening is that when you move your mouse around, system events are being fired and thus we are going to be pumping messages. This in turn means that we will call your function. Now, when you are not moving the mouse, there is little to no events being fired and thus we don't pump messages as often. 

You could try out my theoretical thoughts be setting the Sleep policy to do not sleep and observing if you see the same behavior in both cases of moving and not moving your mouse.  You can set the sleep policy in CVI under Options >> Environment and then selecting an option in the CVI environment sleep policy field. 

Hope this helps!

Best Regards,

[crazyfwed]

Hi Jonathan,

I tried the different settings for the "sleep policy", but the only difference I see is when I debug my application (shift-F5). When I launch the .exe in standalone I don't see any difference.
Anyway, the difference when I do "debug" is only a matter of performance, i.e. with the "sleep more" setting the application is too slow to run in "debug".

As I would like to have a more responsive application, here are some details on how it basically works:
- I have a thread wich polls for UDP packet (using winsock), and when there is a packet, it puts it in a "ThreadSafeQueue" (TSQ) using CmtWriteTSQData.
- my "main" thread is configured to have a callback (using CmtInstallTSQCallback) when this TSQ is filled which constructs some data using several packets and send this data into another TSQ.
- also in the "main" thread, I have a function "Iterate" (which is launched once at the "start" of the application) which looks if any data has been constructed (the actual path of the data is in fact a little bit more complicated) and do a PostDeferredCall on "Iterate" (itself). Doing that, I have some kind of an infinite loop which executes "Iterate".

I have done some more measurements on how often the "Iterate" function is called, and it looks like it is called very often (at least often enough for my needs, even when I don't move the mouse). So it looks like the responsivness "issue" can be due to the TSQ.

Then my question is: is there any way to speed up the TSQ "path"  (i.e. between the WriteTSQ and the effective call of the callback associated to the TSQ) ?
If ever there is something else than TSQ in terms of responsivness, I can be interested.

Thanks in advance.

[menchar]

Maybe you're seeing the effect of the "foreground boost" windows applies to the priority of an app that has just received operator input.

Microsoft's thinking is that if your app has just received an operator input (e.g. mouse movement) then maybe it has something important to do, and it temporarily boosts the priority so that thread runs more often and longer than it would otherwise.

I think you can tailor this behavior.

Menchar

[satyam]

hi jonathan ,

                 i have written an application which runs a test script in a thread.

and when i quit my application ,the thread should be killed and  it should return to the main().

the problem is ,when i call quit in the main() function  using "PostDeferredCallToThread" , the thread ends but the function linked to the thread still executes for a moment  and gives an error.

how to end thread and its related instances completely at any moment

[cdk52]

Satyam,

After PostDeferredCallToThread(), you need to call CmtWaitForThreadPoolFunctionCompletion(). Remember to then call CmtReleaseThreadPoolFunctionID().

You will find further information in the function help.

Regards,
Colin.