I have just installed the newest Intel Fortran version (version 2016.3.210) under Linux (RHEL 6.7)
In my research activity, I routinely run two programs that communicate through named pipes. But with this version they do not communicate any more ...
I have succeeded in writing a very small case that reproduces the problem. Here it is:
1. Creation of the two named pipes
mkfifo a2b.pipe b2a.pipe
2. Here is program a
........................................................................................................................................
program test_fifoa
implicit none
integer :: i
integer :: u_a2b = 10, u_b2a = 11
open(u_a2b, file = 'a2b.pipe', form = 'formatted', status = 'old', &
action = 'write')
open(u_b2a, file = 'b2a.pipe', form = 'formatted', status = 'old', &
action = 'read')
i = 1
write(u_a2b, *) i
flush(u_a2b)
read(u_b2a, *) i
print *, i
close(u_a2b)
close(u_b2a)
end program test_fifoa
........................................................................................................................................
3. And here is program b
........................................................................................................................................
program test_fifob
implicit none
integer :: i
integer :: u_a2b = 10, u_b2a = 11
open(u_a2b, file = 'a2b.pipe', form = 'formatted', status = 'old', &
action = 'read')
open(u_b2a, file = 'b2a.pipe', form = 'formatted', status = 'old', &
action = 'write')
read(u_a2b, *) i
i = i + 1
write(u_b2a, *) i
flush(u_b2a)
close(u_a2b)
close(u_b2a)
end program test_fifob
........................................................................................................................................
4. Here is what happens as seen from a debugger
- Program a writes to a2b.pipe, and returns immediately from the write. So it flushes the unit, and goes to the next part, where it waits for the answer from b
- Program b blocks forever on the reading of a2b.pipe.
- So we have a deadlock ...
5. I have tried to add BUFFERED = 'NO' to the open specifiers, to no avail ...
6. Before this version, I used versions 2011.5.220 and 2013_sp1.2.144 that did not show this problem.
Is it a bug or am I doing something wrong?