do LabVIEW applications and shared libraries have the same name space

[cgibson]

I have an application where I need to call a library written in C. One of the very first functions to call is one that registers a call back function. I am thinking it would be a good idea if I could write the call back function in LabVIEW and then export it as a shared library. One possible reason why this would be good would be so I could pass back results directly to my LabVIEW data structures, instead of polling the library functions. (Right now the call back function is also in C and results are stored in the C application memory space until a read function is called.)

So my question. Will the LabVIEW library functions "see" data structures such as queues  running in the main application even though it is being called from a C program, or are the memories completely seperate?

If it matters, this application is running on a Linux target. The C library provides support for a particular kind of communications protocol. The call back is called when a message is received or an error occurs.

[rolfk]

---

cgibson wrote:

I have an application where I need to call a library written in C. One of the very first functions to call is one that registers a call back function. I am thinking it would be a good idea if I could write the call back function in LabVIEW and then export it as a shared library. One possible reason why this would be good would be so I could pass back results directly to my LabVIEW data structures, instead of polling the library functions. (Right now the call back function is also in C and results are stored in the C application memory space until a read function is called.)

So my question. Will the LabVIEW library functions "see" data structures such as queues  running in the main application even though it is being called from a C program, or are the memories completely seperate?

If it matters, this application is running on a Linux target. The C library provides support for a particular kind of communications protocol. The call back is called when a message is received or an error occurs.

---

The answer to that is not trivial and the fact that it is Linux makes it more difficlut for me since I don't know nearly as much about the details of LabVIEW created shared libraries on Linux. Under Windows IF and only IF the LabVIEW shared library (DLL) was created in the same version of LabVIEW as you call the DLL from, the DLL will run inside the caller context. If the version is different the DLL will be launched in the according runtime system and the objects you mention such as queues and just about anything else using refnums will have no meaning between the LabVIEW DLL that runs in the LabVIEW runtime system and the calling LabVIEW application that runs in the development environment or a different runtime system.

The only parameter types that are safe to pass to a DLL that is not the same LabVIEW version as the calling LabVIEW version are in fact only skalars and the C pointer types. So no refnums, LabVIEW String and Array Handles and such

The same rules will certainly apply to Linux but it may be even more restrictive than on Windows.

Message Edited by rolfk on 04-06-2010 08:20 PM