Gfortran call execute_command_line (... , wait = .false.) still wait issue

Dear all,

I have quick question, I try to plot while running the program. To do so I call

call execute_command_line ('wgnuplot -persist ' // '' , wait = .false.)

since I specified

wait = .false.

therefore the code will not wait until I close the gnuplot popup window. I mean the gnuplot and the program are basically independent. It works fine with Intel Fortran, see below,

However, when the same code compile and run with gfortran, when the gnuplot windows popup, I have to close it, then the problem will continue to run.
Otherwise, if I do not close the gnuplot windows as below, the program pause. Unless I close the popup window, then the code resume.

I am a little confused. The intel fortran and gfortran behaves different.
Does anyone know how to let gfortran really enforce

wait = .false.

so the gnuplot and the code can run simultaneously? 

Thank you very much in advance!

I don’t know how gfortran implements EXECUTE_COMMAND_LINE (I wrote the ifort implementation), but the standard says that asynchronous execution is not required to be supported:

If the processor supports command line execution, it shall support synchronous and may support asynchronous execution of the command line. (16.9.73p4 - emphasis mine)

1 Like

Thank you so much Dr. Fortran @sblionel !!! :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1:
Yeah, the intel Fortran support asynchronous execution when wait = .false.

Hmmm, but like, if asynchronous execution is not supported in gfortran now, then what is the point of using wait = .false.? :slight_smile:

It seems setting wait = .false. should mean the code after

EXECUTE_COMMAND_LINE (xxxx, wait = .false.) 

can just run without waiting xxxx to be finished, is it?

wait=.false. is a request. The “processor” doesn’t have to honor it. You’ll want to check with the gfortran documentation to see whether this is supposed to be supported, and if it is, file a bug report. There are some other things in the standard that are not required to be supported - Annex A in the standard lists all processor dependencies. (Curiously, though - not this one - I will look into that.)

For Intel, the Windows and Linux/Mac implementations are different. Windows uses CreateProcess and WaitForSingleObject - I no longer recall exactly what I did for Linux/Mac, but I know that asynchronous behavior was supported.

1 Like

It has been ages since I had a problem with EXECUTE_COMMAND_LINE(3f). What OS and compiler version are you using? This works as expected with gfortran, ifort, and nvfortran on any Linux and Unix machine I have access to. So this program does not immediately print out the version and compiler information?

program demo_exec
use, intrinsic :: iso_fortran_env, only : compiler_version, compiler_options
implicit none
integer :: exitstat,cmdstat
character(len=256) :: cmdmsg
   call execute_command_line("sleep 30", exitstat=exitstat,wait=.false.,cmdstat=cmdstat,cmdmsg=cmdmsg)
   print '(4a)', &
      'This file was compiled by ', &
      compiler_version(),           &
      ' using the options ',        &
   call execute_command_line("ps", exitstat=exitstat,wait=.false.,cmdstat=cmdstat,cmdmsg=cmdmsg)
end program demo_exec
1 Like

Thank you @urbanjost !
I am on Windows 10 and using Intel OneAPI 2021.4.
The intel Fortran is doing exactly what I want, the code and the gnuplot in call execute_command_line(gnuplot 'gnuplot persistent', xxx, wait = .false.) they run independently. so I can get real time plot all the time. Then gnuplot can reread the file and plot like every 1 second interval.

However gfortran at on my Windows behave like I described, the wait = .false. have no difference from wait = .true..

I also tested gnuplot on ubuntu with gfortran with wait = .false. . This time wait = .false. seems working, However the gnuplot popup window does not update automatically at every 1 second. I need to close the gnuplot popup window, then it popup gain, close, popup gain, repeat… I do see each time the content in the popup window updates, but I have to manually repeat this close->popup loop,

However, intel OneAPI on windows and ubuntu behave the same, I do see the gnuplot update in real time. So it seems gfortran’s wait = .false. is different from intel’s. I would prefer the way Intel does.

In terms of speed, on Linux, gfortran is not bad actually. Roughly the same as Intel’s, perhaps 10-20% slower but still decent. However, intel’s performace is consistent on windows and linux. While gfortran’s speed on windows (at least for my code) seems is about 2-3 slower than intel’s. My gfortran flag is

-Ofast -march=native -flto