topic question about callbacks in LabWindows/CVI

question about callbacks

mzimmers — Thu, 21 Mar 2013 01:30:22 GMT

I'm trying to design a small program that involves TCP socket reads and writes. In the help for the ConnectToTCPServer() function, there's a note about the callbackFunction:

The callback function should be short and should return as soon as possible.

My question is, does this statement apply principally to the ConnectToTCPServer() function, or to all callbacks? It seems that once I've called RunUserInterface(), pretty much all my processing will be within callbacks (or routines that the callbacks call).

Am I missing something here?

Re: question about callbacks

test_man — Thu, 21 Mar 2013 15:05:04 GMT

To it's callback function.

Rif.: question about callbacks

RobertoBozzolo — Thu, 21 Mar 2013 16:47:21 GMT

Generally speaking, that warning applies to all callbacks: a control callback that takes too long to terminate blocks all user input on the user interface. One very common question on this forum is indeed "I have a callback that executes a test but I cannot stop it pressing a stop button because it is unresponsive!" CVI offers ProcessSystemEvents () function exactly to permit processing events in case of a long callback that blocks out other events, but it must be used with cautions: as you can read in the help for the function, Take care when using ProcessSystemEvents, because it can allow other callback functions to execute before it completes.

Additionally, there are several methods to execute code out of a control callback or without blocking the user interface:

UI timers
Asyncronous timers
Functions called via PostDeferredCall
Threads other than the main thread

In case of a long lasting procedure, I strongly encourage you to handle it in one of these methods instead of running it inside a control callback with embedded calls to ProcessSystemEvents () .

Rif.: question about callbacks

mzimmers — Thu, 21 Mar 2013 17:25:30 GMT

Interesting. This raises a different issue: will one callback block another?

I've constructed my program like this:

buttonCB:

{

write a TCP message

wait for newdataFlag

process new data

}

TCPCB

{

read TCP reply

set newdataFlag

}

(newdataFlag is a global variable.)

Is there anything intrinisically wrong with this design? Will the fact that I'm in buttonCB prevent TCPCB from executing?

Rif.: question about callbacks

mzimmers — Thu, 21 Mar 2013 19:59:46 GMT

OK, I did a bit of research, and it turns out that my concern is indeed the case. So, I've restructured the program like this:

buttonCB:

{

write a TCP message

}

TCPCB

{

read TCP reply

process new data

}

I'm not thrilled with it, because my TCP callback isn't as brief as I'd like it, but...it works. If I wished to improve on this, which of the options that Roberto recommended above would seem preferable in this application?

Thanks.

Rif.: question about callbacks

RobertoBozzolo — Thu, 21 Mar 2013 23:49:39 GMT

I have little experience with TCP libary, but according to this page you must process messages in order to receive events in the callback; given this, your rewrite is on the right path. You could have inserted a ProcessSystemEvents inside your loop, but the change in logic is indeed better.

You could make your callback faster by moving processing out of it:

TCPCB

{

read TCP reply

PostDeferredCall (ProcessingRoutine, NULL);

}

Rif.: question about callbacks

mzimmers — Fri, 22 Mar 2013 17:02:07 GMT

Hi, Roberto -

I tried the PostDeferredCall(), and it seems to work well. The documentation (ie, the online help) is a bit confusing, though. Am I correct in my understanding that this will not execute until ALL pending callbacks are finished, or merely the TCPCB that posted the deferred call?

Rif.: question about callbacks

RobertoBozzolo — Fri, 22 Mar 2013 22:40:57 GMT

I am not sure about that. If pending events are lined up in a single queue that is processed when running function has finished, the deferred callback will be executed after already raised events but before others that may happend after PostDeferredCall. This may not be true if events have priority flag associated to them so that they may be processed in an order other than chronological one. I tend to consider the first option is the right one but I am not sure.

Additionally, consider that you may spawn an separate thread to process some events and launch the deferred function in that thread with ProstDeferredCallToThread (): this will definitely alter the order of event processing, especially with multicore PCs

Rif.: question about callbacks

mzimmers — Sat, 23 Mar 2013 22:28:54 GMT

I'd like to pursue the issue of callbacks vs. deferred functions a bit more. My application has a "START" button. When the start button is pressed, it's callback sends a message through a socket to a connected device. Upon receiving this message, the connected device sends a block of data to the program (through the same socket). Once the program processes the data, it sends anotherh command for more data, and continues to do so until a "STOP" button is pressed.

I've tentatively designed my program like this:

ButtonCallback:

{

set g_send to true

send a "SEND" command to the device

}

TCPCallback:

{

read the data from the socket

post a deferred call to process the data.

}

ProcessDataCallback:

{

process the data, display, etc.

if (g_send == TRUE)

send another "SEND" command to the device.

}

(let's ignore for now how g_send is set to false)

If my understanding of how callbacks work is correct, TCPCallback and ProcessDataCallback will cause each other to cycle until g_send is set to FALSE.

From my very brief description above, can anyone see a flaw in this design? I welcome any input, but I'm particularly interested in whether a call could somehow be blocked, or fill up and eventually overrun the call stack.

Thank you for any input on this.

Rif.: question about callbacks

RobertoBozzolo — Sun, 24 Mar 2013 11:23:37 GMT

I see no real flaw in this design: the deferred callback is fired by TCP callback after receiving a complete message and fires a new message to the device only after terminating handling data.

This structure stresses the system (intended as external device and PC application) to the maximum possible throughput, in the sense that each step is executed immediately after the preceding one is completed, without any pause or delay.

Rif.: question about callbacks

mzimmers — Sun, 24 Mar 2013 14:18:30 GMT

That's a good point about the lack of delays. Perhaps I should put in a short delay after sending the "SEND" commands?

Does CVI have any timing mechanisms better than the Sleep() function that's provided by Windows? I've heard that Sleep isn't very precise.

Rif.: question about callbacks

mzimmers — Sun, 24 Mar 2013 15:53:17 GMT

Ah..Delay(). Very good.