11-05-2024 10:52 AM - edited 11-05-2024 10:53 AM
I have created an app that works without issue. Takes a file, parses the file, and creates a new file. Depending on the file it is fed, it may call a different parser (there are 2 parsers internally, potential for more). But, it works without issue in Dev Env.
What does "work without issue mean?" Well, I'll tell you. As a VI in LabVIEW environment, I feed it all the different files and they are correctly parsed and the correct file is created. As a built executable, I feed it all the different files and they are correctly parsed and the correct file is created. As a DLL called by Python, 1 of the parsers work... the other just freezes.
The issue does NOT lie with Python as it's just feeding it the filepath and getting the finished filepath as a return. Why is this not the issue? Cuz it makes no sense for that to work for 1 and not the other. Again, all files have been tested against the executable version and the VI version.
There's something LabVIEW to DLL that Windows, or RTE, or something doesn't like. Are there any special considerations that need to be kept in mind when building a VI that will be eventually made into a DLL? Like FPGA? You can't use the entire pallet when making FPGA.
Things I am using: Data Value References, Queues, FGVs. But both parsers use these. The only significantly different thing about the parsers, one parser runs two loops asynchronously.
11-05-2024 10:56 AM
In your dll build specification there is something related to parallel execution. Make sure it is enabled.
11-05-2024 11:03 AM
@billko wrote:
In your dll build specification there is something related to parallel execution. Make sure it is enabled.
I'm digging through all the build properties, but not seeing anything related to parallel execution. You might need to spoon feed me on this one.
11-05-2024 11:15 AM
In my LV 2020 it's in advanced --> Execute VIs in a private execution system.
11-05-2024 11:22 AM
@billko wrote:
In my LV 2020 it's in advanced --> Execute VIs in a private execution system.
2020 as well. I have this checked. I do see in the header file: void __cdecl SetExecuteVIsInPrivateExecutionSystem(Bool32 value);
Is there something in Python (or other language) that needs to make sure it enables it? Actually feed it a true?
11-05-2024 11:29 AM - edited 11-05-2024 11:34 AM
Just off the top of my head.... does EXACTLY one of the file parsers depend on DOMUserDefRef.dll? W3C has never released a threadsafe version of that library (and since it does file reads and writes from disk hardware would not permit multiple concurrent disk IO anyway)
That's not saying that the DLL you build shouldn't work the same as a compiled LVObject...just food for thought in understanding what went wrong. Try Unchecking the use private execution system option.
11-05-2024 11:55 AM
@JÞB wrote:
Just off the top of my head.... does EXACTLY one of the file parsers depend on DOMUserDefRef.dll? W3C has never released a threadsafe version of that library (and since it does file reads and writes from disk hardware would not permit multiple concurrent disk IO anyway)
That's not saying that the DLL you build shouldn't work the same as a compiled LVObject...just food for thought in understanding what went wrong. Try Unchecking the use private execution system option.
Okay, so this is interesting. To answer your immediate question, I have no idea. But based on context, the parser that does work actually does simultaneous R/W. The parser that is not working actually does wait for the file to be read before writing back to disk.
11-05-2024 11:59 AM
I tried it Unchecked. No change to results. One parser works, the other does not.
I noticed, though, the header file does not change.
void __cdecl SetExecuteVIsInPrivateExecutionSystem(Bool32 value);
11-05-2024 01:12 PM - edited 11-05-2024 01:14 PM
@LuminaryKnight wrote:
@JÞB wrote:
Just off the top of my head.... does EXACTLY one of the file parsers depend on DOMUserDefRef.dll? W3C has never released a threadsafe version of that library (and since it does file reads and writes from disk hardware would not permit multiple concurrent disk IO anyway)
That's not saying that the DLL you build shouldn't work the same as a compiled LVObject...just food for thought in understanding what went wrong. Try Unchecking the use private execution system option.
Okay, so this is interesting. To answer your immediate question, I have no idea. But based on context, the parser that does work actually does simultaneous R/W. The parser that is not working actually does wait for the file to be read before writing back to disk.
What file types does the working parser work on? Ditto the problem parser. What is different about the files? Is DOMUSERDEFREF.DLL in dependencies?
11-05-2024 01:28 PM
Let's get to more basic things first.
What is the entire header file created from LabVIEW when you build the DLL?
What is the Python ctypes definition for the import of the relevant functions?