sleepqq() or inquire() issue

[gib]

My program uses a file and a socket to communicate data between two processes. The Fortran subroutine (in a DLL) checks that the file does not exist, then creates it and sends a socket message to the C++ process. After the C++ code is finished with the file it removes it. The Fortran code uses inquire and sleepqq to make sure that it is timee to create the file:

inquire(file=fname,exist=ex)
if (ex) then
! call logger('waiting for file removal ...')
do
inquire(file=fname,exist=ex)
if (ex) then
call sleepqq(100)
else
exit
endif
enddo
! call logger('file removed')
endif
open(nfpos,file=fname,status='new')

In some situations the Fortran code returns the error message: Permission to access file ... is denied.

I don't understand how it could not be possible to create a file when inquire() says that no file of that name exists. What am I missing?

I'm using Fortran and C++ 11.0.072

[onkelhotte]

The inquire / sleep method is not very elegant.

Take a look at the IVF DLL_Shared_Data Example how you can solve this with Mutex.

Markus

[gib]

Thanks, but I don't want another way to do this (I'm sure there are many). I just want to know why the inquire is not giving the expected result.

[Steven_L_Intel1]

I have seen cases on Windows where a file is deleted but remnants exist in the Windows data structures for a short time after the delete occurs, and you can get odd results such as this. Try adding a 500ms sleep before the OPEN and see if that helps.

[gib]

That seems to work reliably with a sleep of 1000 ms, but not with 500 ms. Much too slow to be feasible in this case - updates can be several per second. Most surprising. I presume it's related to how the multithreading is being handled. Things are fairly complicated on the C++ side, which is using Qt and also VTK libraries (the info in the file is used to create an OpenGL scene). The file remove is actually a Qt command. I can fix it by replacing the remove by rename and remove. In this case it doesn't matter how long the remove takes, because the reading of the file created in Fortran is in the same thread of execution as the remove. What I don't understand is that with this measure the program can run fast (several updates per second) - there is no indication of long waits for the remove to complete.

Not a Fortran issue, anyway.