From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
10-22-2020 10:39 AM - edited 10-22-2020 10:54 AM
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/
10-22-2020 12:02 PM
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.
10-22-2020 02:29 PM - edited 10-22-2020 02:44 PM
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.
10-22-2020 03:09 PM
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.
10-23-2020 10:10 AM
The integer value not being the same makes sense if the two processes aren't maintaining the same length list of descriptors.