> The Call Library Function Node has a undocumented upper left input > wire, left of the output wire, corresponding to the return value, if > any. > > It looks like I can use this wire to influence the order in which > different Call Library Function nodes execute. Is this a documented > feature I can rely on or am I walking on thin ice here ?
I don't know if this deserves to be called undocumented. It is simply an input to the node that the return value can be written into. It is hardly worth doing since the return types are limited to simple types. As you noted, like all wires to a node, it will affect execution order. > > Furthermore I call the same non-thread-safe function twice in my VI, > the Call Library Function Node of each being set to "Run in the UI > Thread". If I don't enforce the functions to be called in sequence and > I change the value of an unrelated VI control while the VI is running > (in a While loop), the function generates an error as if it was called > by LabVIEW assuming the function was thread safe. This behavior is > very repeatible. > If I enforce both instances of the same function to be called in > sequence (by wiring the output value of the 1st function to the > undocumented upper left input wire of the 2nd function), all problems > are gone. > > Normally I'd expect that changing a totally unrelated VI control > (double) which also runs in the UI thread may have no influence at > all, but running the VI indicates otherwise. I tried to reproduce the > problem based on a simple example, but I'm unable to obtain the same > effect. > I can comment, but I don't know if I can explain it. When you set a DLL to run in the UI thread, it simply means that LV will post a message to the UI thread to run the node instead of processing UI events. While running the DLL in the UI thread, LV cannot and will not process mouse clicks, keys, or anything else unless the DLL "pumps messages" -- a Windows technique for giving the thread to another app for processing a message. If it is doing this, it will allow LV to process other UI messages, including execution of other UI code such as property nodes and yes, other DLL calls. What this means is that not only is the DLL function not reentrant, but by pumping messages, certain other functions that interfere with its execution will not be executed. It is up to the user of the function to arrange for this to be true. As I said, I can't say for certain that this is what is happening. If you have debugging ability on the DLL, you might try setting breakpoints or print statements in the DLL functions. Since these change the timing, you might need to use a static global in the DLL to catch the simultaneous calls. Set it to TRUE in the beginning of the function, to FALSE at the end, and test it in the other. Break if the test ever finds that you are in both functions at once. And if this makes your head hurt, this is why it is best to use reentrant functions or protected functions when possible and affordable. Greg McKaskle
