When I call the function "ProcessSystemEvents," it often doesn't get TCP interrupts

[D. Haaland]

I have several executables running on several computers. The executables were developed in LabWindows, and they communicate with each other by TCP. If I need to delay in a function, but process input while delaying, I call "ProcessSystemEvents" in a loop. However, if a TCP message is received in this time, it doesn't call the TCP callback function until I exit the loop, and get back out to the "RunUserInterface" function. Is there a way to receive TCP messages while waiting in a loop?

[JuanCarlos]

Hi,

I did some testing here and could not replicate that behavior, what I did is the following:

1.-Opened the TCP server example.
2.-Comented out the RunUserInterface call.
3.- Created a while loop that runs forever ProcessSystemEvents()
4.-Ran the example together with the client and it worked.

I Tested this is CVI 6.0 and 7.0, is there anything that I'm missing to replicate this? Do you have multiple threads running?

Please keep me posted.

Regards,

Juan Carlos
N.I.

[aperez]

With the information you provide, it is not clear how often you are calling ProcessSystemEvents and how long the loop takes. But it is possible that when ProcessSystemEvents is called, there are no TCP events on the queue. Keep in mind that TCP events are generated every "now and then", and not necessarily as soon as the data is ready. The Winsock library looks at the socket to check if there is data available for retrieval on a periodic basis - not as soon as it arrives.

It is also possible that the TCP events are sent to another thread; remember that TCP events should be handled in the thread where the client/server is registered. So make sure you are not calling ProcessSystemEvents in the wrong thread.

There are several reasons why you might be missing those TCP events. Here are some things to look for:
- if you have a timer on your user interface that's running too fast, it is possible that the TCP events never get a chance to be processed.
- if your program is spending too much time processing UI, you might be better off creating another thread just for TCP reads/writes
- if you are calling ProcessSystemEvents sporadically or not often enough, it is possible that the TCP events are not generated or handled on time.

The way to receive/handle TCP messages while waiting on a loop really depends on your application, the amount of time spent in the loop (which should be short if you are inside a callback) and the nature of the reads or writes you are expecting to process.
One possible scenario would be for you to automatically call the TCP callback from inside the loop instead of relying on ProcessSystemEvents which takes care of many system and UI events, not just TCP; this could be dangerous. If you call the TCP callback directly from inside your loop, make sure you are handling the case where the read times out - inside the TCP callback. A timeout just indicates that there is no data ready at the moment and is not an error per se. Here is example code that would handle this case:

if (xType == TCP_DATAREADY) {

// Read the message size.

messageSize = -1;
DisableBreakOnLibraryErrors();
error = ClientTCPRead(gConnection, &messageSize, sizeof(messageSize), 100);
EnableBreakOnLibraryErrors();

if (error != -kTCP_TimeOutErr)
tcpChk (error);

// Read the message. Note that the message could be empty.
if (messageSize >= 0) {

assert(messageSize <= sizeof(dataBuf));
bytesToRead = messageSize;

while (bytesToRead > 0) {
tcpChk (ClientTCPRead(gConnection, &dataBuf[messageSize - bytesToRead],
bytesToRead, 0));
bytesToRead -= error;
}
}}}

Hope this helps.

Azucena

[D. Haaland]

No, there is only one thread in each executable. There are multiple executables running on each of several machines. However, the the ProcessSystemEvents function is called from a dll within the main thread (the only thread) of each executable. When I step through the program that is receiving the event (including the dll), I find that the ProcessSystemEvents function does not capture the TCP message, but when I get out of the loop, and out of the dll, the TCP message is waiting - and has been waiting for several minutes while I stepped through the dll.

[D. Haaland]

Perhaps the key to my problem is your comment that the time spent in the loop should be short if I am in a callback. On thinking about it, I realized that the loop is within a function that is called from a TCP callback - in response to a TCP message. Is it the case that a TCP callback will not interrupt another TCP callback - or the functions that are called from within another TCP callback?

[Pierre_63]

If you have to dealy a function call, it'ss probably better to use PostDeferedCall( or others functions like that.

[Rafi2003]

can you give more details about this procedure?
for example, what does tcpChk do?

Thanks