File acess problems (and common blocks in DLL)

File acess problems (and common blocks in DLL)

Hello,
I have two old fortran programs that talk to each other using the text files. One of these was recompiled as a DLL and ever since then (actually since switching to the Intel compiler from the discontinued DIGITIAL Visual Fortran) and error would occasionally (not always) occurs, where one or the other of the two programs would have issues opening a text file written by the other one.
The resulting error is something like (sorry, had too translate from German): ====forrtl: The process with a File with an opened domain, which is assigned to a user, is not possible/allowed
Followed by: forrtl: severe (38): error during write, unit 88, file....
The error happens occasionally, even with identical instructions, the program would run couple of times ok, have an error on one or two runs and then run ok again.
I was looking through the code and everything seems legit. I do have some concerns that the file initialization and actual writing to the file happen at different subroutines. Also the file being written too is often being reused from the previous iteration. The program1 and 2 can iterate between each other up to 50 times writing/overwriting back and forth into the same file, but each program closes the file when done. E.g.

Subroutine Init_File
...code
Open(10, File = FileName, Status ='UNKNOWN')
...code
End Subbroutine
 
Subroutine write_file
Write(10,*) InputString1
...code
End Subroutine
 
LOGICAL FUNCTION Program_Main
...code
Close(10)
END FUNCTION

I have also been trying to get the two programs to talk to each other without the text files in-between, and it works fine when I send over the needed data from the DLL using a derived type. But I was also trying to make the change as minimally intrusive as possible (because the DLL is also used by other programs). Hence I tried to send the data over using a common block:
! Program 1
REAL(8) FUNCTION Program1(Infile, Outfile)
!DEC$ ATTRIBUTES DLLEXPORT :: Program1, /X/
USE MODULE_with_custom_type
COMMON /X/ DataExchange
Type(CustomType) :: DataExchange
...code
Return
END FUNCTION
! Program 2
MODULE DLL_Interface
USE MODULE_with_custom_type
INTERFACE
 REAL(8) FUNCTION Program1(Infile, Outfile)
 !DEC$ ATTRIBUTES DLLIMPORT :: Program1, /X/
 IMPORT ::  CustomType
 CHARACTER(200) Infile, Outfile
 Common /X/ DataExchage
 Type(CustomModule):: DataExchange
END INTERFACE
END MODULE
! in main program
USE DLL_Interface
DUMMY = Program1(Infile, Outfile)
...

The question is how to I make the common block visible to the main program? I tried declaring without the interface: it works but eventually causes call stack corruption.

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I'm not sure I fully understand the description of your problems, but...

1. If you are sharing an I/O unit between an executable and a DLL, make sure the executable is linked against the DLL form of the run-time libraries that your DLL is also linked against. If either of them is using static libraries, you'll have problems. This setting is under Fortran > Libraries > Use Run-Time Libraries. I will also comment that sharing a text file between programs doesn't work well on Windows, especially if both are writing to it.

2. There is a worked example of sharing data across programs through a DLL in sample DLL > DLL_Shared_Data

Steve - Intel Developer Support

From your code sample supplied, you do not appear to manage error conditions on your open statement.

Is it possible for both programs to be running simultaneously, or do they only run in sequence ? If simultaneously, then you may need to manage waiting for the file to be ready. There is also the potential of a 3rd party program / process accessing the file, say you viewing the file, or a background backup process.
It would not be too difficult to put a test on the open and then a wait and retry if not available. Some error report and a limit on the number of re-tries would help.

I am assuming that once the file is open successfully, the read or write proceeds ok, although there is always the possibility of a failure. A clear message why would always help.

If you are runing on a network, you will be surprised what can occur.

John

Review logic of the processing because it looks like there is No a correct handling of End-Of-File case.

ERROR_HANDLE_EOF - 38 - Reached the end of the file

Take into account that this is a possible reason ( still Not proven ) and it needs to be investigated.

Leave a Comment

Please sign in to add a comment. Not a member? Join today