TCP callback is halted waiting on completition of WaitForSingleObject

[clabbott]

In my transmit function I am sending some data to the server. After sending the data, I call WaitForSingleObject to generate a timeout if a response is not received from the server. It seems as if the wait function is halting the callback also. After the timeout occurs the callback then begins executing. What is going on? Should I have the callback in a seperate thread?

[menchar]

When you use WaitForSingleObject, the calling thread is suspended, and will be resumed when either the object becomes signaled or the timeout occurs. It's pretty clear that your TCP callback isn't executing because the thread isn't running: it's "asleep" waiting for the object to become signaled. This is a problem (or maybe it would be fairer to say a complexity) of using CVI callbacks and Win32 API calls such as WaitForSingleObject. If you were to make a loop with ProcessSystemEvents and WaitForSingleObject with a short timeout (e.g. 100ms), you would achieve the desired behavior of response to your TCP event (callback) as well as not spinlocking while waiting for it to complete. This same general issue exists with all CVI callbacks, including those from GUI panel
controls.

[aperez]

I would suggest that you use another thread for TCP/IP calls. For help with multithreading programming, see the CVI Multithreading Overview (cvi\bin\MultithreadingOverview.pdf) and the multithreading example programs (cvi\samples\utility\Threading).

Regards,
Azucena

[menchar]

Another thought:

Many designs use a separate thread for the TCP callback if for no other reason than the fact that TCP guarantees a reliable byte stream, NOT a message stream. So,you can use the separate thread to assemble the incoming byte stream into messages and then notify the main application only when an intact message is available.