CVI threads and callback

[Simondon_Laurent]

Hello,

My questions (at the end) are mostly around how CVI handles callbacks and threads in my case to be able to handle multiple TCP socket links.
I'm looking for some good pratices as my code works well but uses more CPU that i would like (about 1 full core on a six core computer).
I have to add several TCP socket links to an existing software with multiple acquisitions sources (1553, analog, digital,...).
The max expected acq frequency on those TCP socket is about 200Hz with about 2000 bytes for each frame (1 socket stream at 200Hz and 2 others at 1Hz).
I joined a very short sample of the TCP socket code.

Here are the basic ideas for the code :
- In the main function creation of a new thread pool to allow several threads to handle TCP sockets
- Creation of a thread called "A" to run the test sequencer (several days of test). It allows the main thread to handle UserInterface callbacks.
- In thread "A" creation of three threads "B", "C", "D" to open and handle TCP sockets callbacks (each thread loops on ProcessTCPEvents()). Might not be useful....
- Then threads "A" waits for test end (Acquisitions are driven by another 1553 thread and it tells to the rest of the software when to end acquisition with a global variable)

The idea behind this choice is to minimize the latency of the TCP callback execution ans use as few ressources as possible waiting for the test to end (loop on ProcessSystemEvents() in thread "A")

Some debugging tests with a unique TCP socket showed that :
the thread that executes the TCP callback is always the one where the communication socket has been opened :
- When Thread "B" loops on ProcessTCPEvents()
- Even When "B" does not handle events (but has opened the socket). In that case the callback must have been launched by RunUserInterface() to be is execute in thread "B".

So :

In theory is there a real benefit to force another thread "B" to handle events to minimize the risk of acquisition loss with the 200Hz TCP stream ?
-> There are no overly time consumming functions to be executed by the RunUserInterface thread but i have several callbacks to update graphs (PostDeferedCall with mostly value attribute change and a single ProcessDrawEvents at the end)

IS there a way to prevent RunUSerInterface to handle TCP events and use a separate thread for this ?
In that case is there a way to specify wich thread should handle the TCP callback (it seems that it runs in the thread that opened the socket but can it be changed ?)

Thanks for your advices,