
----- Original Message -----
From: "Jerry"
Francisco Javier Porras Gálvez
writes: Hi, Jerry.
Thanks for your support!
I hadn't any idea about what a socket was, but after "googling" a little and read about in NI pages, I have it clearer now.
LabView uses a tool called DataSocket to share data between different applications or/and the internet. Moreover, I "discovered" that LabView includes a set of C++ libraries in what is called "Measurement Studio". One of this libraries implements also "DataSocket", and in NI forums they state is possible to share data between two applications in C++ and LabView using this DataSocket tool.
So, I think this is the right direction. Your clue was really useful.
Thanks, Francisco
Sorry for the confusion: Actually I wasn't suggesting that you use a socket to communicate between two applications. Although if you want to be able to run the C++ stuff on a different machine or retrive the data from more than one application then this is a good move. If all you want is Labview to talk to another thread in the same application then use a DLL with a separate thread. There is no reason to make a socket if you can use a DLL instead unless you need to be able to connect to the DLL from more than one app or from an app on a different machine.
The only reason I mentioned the socket stuff was as an example of something I needed to run a thread in a DLL to accomplish. I guess I ramble a bit too much :-)
Jerry
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi, Jerry. Hehehe, ok, don't worry. I think this "DataSocket" stuff it's going to be very useful for another application I have to deal with. So, in the end, it was very helpful:) So, your suggestion is to use the first aproach, isn't it? This application will run on Windows. In "Cplusplus" forums I was suggested to use Boost because Windows API threads aren't very friendly with synchronization. I don't know much about threads, but what I find more difficult to asume is the fact of creating a thread with a function, and then, after this function has ended, share data with the created thread using another function. Due to this, I can't use OpenMP, for example, because its thread behaviour follows the fork-join model. Anyway, I'll follow your advice and try to integrate your example in my code. Thanks for the attached code! Francisco