Trying to Follow White Paper - Running a LabVIEW Application on Linux Without a Graphical User Interface

[RVallieu]

Playing around further - I was able to get the C Code that takes over the port monitoring from xinetd to pass the SocketFD to LabVIEW - but this is where it falls apart, as expected.

I have no valid way of using that FD (file descriptor) to write and read from the port.

The PipeVIs do not work with the FD.

I tried just using the making a simple .so for the C write function that uses the FD.  That appears to work, it compiles and I can access it with a Library Interface Node, but the FD trip from the main C to LabVIEW, then LabVIEW to C write() loses the "context" of the FD connection to the memory descriptor table I suppose.

Although the write() called by the LabVIEW Library Interface Node does return it wrote out the correct number of bytes and not a -1, nothing shows up on on the client side.  I'm not sure WHERE the string I wrote ended up, but it wasn't on the SocketFD.  😄

I'm thinking about how to set up Linux to launch my EXE and make sure it stays running (not that I expect it to ever crash).  I'm looking at the Monit tool. https://mmonit.com/monit/ , although that costs $, and Supervisor http://supervisord.org/

[rolfk]

Have you marshalled the file descriptor through some means as explained in this post or simply send the numeric value over?

File descriptors are not direct inode references but rather process specific indices into an array of file entry records that identify the actual stream, socket or file inode.

[RVallieu]

I was evidently treating the FD incorrectly using a LabVIEW VI in a .SO for the main socket monitor C program to pass the Int_t value to LabVIEW.

Though I am not sure using this RX method being called by LabVIEW by using a Library Interface Node would work once the FD is read by LabVIEW and in its application space.

[rolfk]

I'm not sure either but supposedly those methods marshal the file descriptor between process spaces. Basically the fd is an int value that only has a meaning in th context of the process in which it was created/opened. It maps to a data structure that is maintained by the C Runtime library for the actual process which does things like buffering and such. It also contains a v-node pointer which points to the kernel structure that manages the actual file/directory/socket/device in kernel space.

It also is indicated by a remark that supposedly the integer value of the two file descriptors is not the same in the two processes despite being for the same file/device.

[RVallieu]

The integer value not being the same makes sense if the two processes aren't maintaining the same length list of descriptors.