signals and open files

[ryofurue]

Hello all,

I'm wondering what executables produced by ifc7/ifort8 do
on receiving signals. Where can I find documentation on
the subject? I tried the index of the ifc7 Language guide
but found no entry for "signal". I'm also wondering what
happens to opened files if the program is killed before
the CLOSE statements are executed.

The reason I ask this question is that I want my running
Fortran program to close files before dying on receipt of
a signal, say, SIGTERM or SIGHUP or whatever. (I'll elaborate
this at the end of this posting.)

I tested ifc7 using the attached little program. I compiled
it without any compilation options, ran it, and while it's
waiting for the user's keyboard input, sent it a signal from
another terminal. I tried SIGTERM, SIGHUP, and SIGINT.
In either case, the program produced a file of 8192 bytes.
The correct size is 8008 bytes. I examined the file and
found that the first 8008 bytes are correct, so that you
can open the file and correctly read the first record.
I guess the extra 184 bytes would have been removed if the
CLOSE statement had been executed.

1) Is this behavior guarranteed? If it is, your data can
always be retrieved even when the program is killed by a signal
after the completion of a WRITE statement but before the
execution of the CLOSE statement. I mean, if the Fortran
runtime always writes at least the whole data plus the 4-byte
record trailer on execution of a WRITE statement, we'll end up
with a correct file plus some garbage possibly appended at
the end. I wonder if my test case was just lucky.

2) Does one of the signals tell the runtime of a running
Fortran program to close all files before exiting? If not,
do you think it is reasonalbe to request Intel to implement
the feature? I once asked a vendor for this feature. They
picked up one of the signals for this purpose. So, when you
send SIGTERM or SIGINT, your program stops immediately,
but when you send that certain signal, your program closes all
files before stopping.

I want this because my programs typically run for days and
sometimes I need to kill them prematurely for various reasons.
I don't want to lose outputs even I kill them; if I have correct
outputs, I can continue the calculations from the point I killed
the programs. My programs write intermediate results at every,
say, 20 minutes, and the data isn't very large, so that it's
very unlikely that I happen to send the signal during the
execution of the WRITE statements. *If* I were the author of
the programs, I would close the output files immediately after
writing to them, so that I would be able to kill the programs
safely almost at any time during their execucutions. . . .

Thank you,
Ryo
=========================================
program try
implicit NONE
integer, parameter:: N = 1000
character(128):: tmp
real(8):: a(N)
integer:: i

open(unit = 10, file = "tmp.dat", form = "UNFORMATTED", &
access = "SEQUENTIAL", status = "REPLACE")

a = (/ (1.d0 * i, i = 1, N) /)
write(10) a
write(*,*) "1"; read(*,*) tmp

a = (/ (2.d0 * i, i = 1, N) /)
rewind(10)
write(10) a
write(*,*) "2"; read(*,*) tmp

close(10)
end program try

[Steven_L_Intel1]

User's Guide..Error Handling. This is for ifort 8 - I am not sure what version 7 had to say about this.

[ryofurue]

Thank you, Steve.

I tested ifort8 and found that with SIGINT and SIGHUP, a correct file is left. That perhaps
means that the runtime closes open files before exiting, even though the CLOSE statement
hasn't been executed. I like this very much!

So, my remaining question is, is this behavior guarranteed? I looked into the section
"Signal Handling" of the ifort8 User's Guide:
http://www.ncsa.uiuc.edu/UserInfo/Resources/Hardware/XeonCluster/Doc/Intel_8.0.044/f_ug1/index.htm
but it doesn't say what the runtime does on receipt of signals.

Regards,
Ryo

[Steven_L_Intel1]

Guaranteed may be too strong a word. The runtime establishes an exit handler so that it can cleanly close all open files on image exit, but there are many things that could prevent that from happening outside the runtime's control. My advice is to design your application so that it can handle the files not being cleanly closed.

[ryofurue]

Thanks. That's basically what I wanted to know.

> Guaranteed may be too strong a word.

I understand. But, I would like to see that this
feature be "elevated" to the "documented" satatus
:). You can't "guarantee" that files won't be
corrupted when the program exits on a signal, but
you could promise, by "documenting" it, that the
signal handler be set.

> My advice is to design your application so that
> it can handle the files not being cleanly closed.

I'm a bit puzzled with this. Do you mean that we
should reduce the chance of file corruptions by,
for example, closing files immediately after writing
to them? If so, I completely agree. Next time I meet
him, I'll pass this advice to the author of the
program I'm using. :-) Or, on the other hand, do
you mean that we should be prepared somehow to handle
corrupted files left by a Fortran program? I don't
know how that works because the way files are corrupted
would be different from compiler to compiler and from
situation to situation.

Anyway, thank you for your answer.

Ryo

[Steven_L_Intel1]

What I'm saying is that there is a risk that your program could terminate in a way that prevents the RTL from properly closing the file. You have to decide if you can live with that level of risk, or you need to take extra steps to account for it. There is not a single answer that fits all applications.