12-10-2024 07:58 AM - edited 12-10-2024 08:53 AM
Hello,
I have to use a 3rd party .net library that relies on the windows message pump to work. I reference this library from within my own .net class library wrapper (its a part of a wider solution); and instantiate it on a separate STA thread that has a custom implementation of a message pump. This works well - tested on a CLI app, I can operate the 3rd party library with no issues.
How should I create a reference and invoke from within LV? When I log from inside the message pump loop thread, running from LV, only a few messages end up in my pump queue (despite the message pump loop continuing to iterate). Here is how I create and invoke my .net library from LV:
I tried reading on about how LV manages threads but was unable to piece together a coherent solution. I would appreciate if anyone has some information or a solution on how I could push this issue forward. Please let me know if you need more details. Many Thanks in advance.
12-10-2024 09:51 AM - edited 12-10-2024 09:55 AM
LabVIEW has its own message pump in its main thread (the famous UI thread aka root loop for folks somewhat familiar with this). As such if you want to have your own thread with its own message pump, you have to be VEEEEERY diligent to not somehow have any synchronization with the LabVIEW UI thread. Nothing you ever invoke for that component from LabVIEW may EVER be depending on anything that LabVIEW executes in the UI thread or you will very quickly get into a mutual exclusion situation.
Unfortunately there is not a lot of control in how .Net constructors and methods are invoked. At least for the constructor, I have a hunch that LabVIEW will actually involve some UI thread synchronization, since it is likely accessing some global resources that help it maintain the .Net functionality. Method calls I would expect it to honor the desired threading model of the actual .Net assembly.
But it may be actually quite a bit easier to have an external .Net application doing that complicated message pump business and communicating with that application through TCP or some other Inter Process Communication method from LabVIEW.