fopen(log_file, "a");

[Arturo Ordaz]

Has anyone run into documentation that describes how fopen(log_file,
"a") behaves when it is potentialy used (called/referenced) 1000's of
times an hour on a single resource file? I am trying to find out the
adverse effects of fopen(log_file, "a") potetialy being called at the
same time and trying to open the same file. Is the file locked when
fopen(log_file, "a") is used?

I would appreciate any information that anyone might have,

Cheers

 

[Vu Pham]

Has anyone run into documentation that describes how fopen(log_file,
"a") behaves when it is potentialy used (called/referenced) 1000's of
times an hour on a single resource file? I am trying to find out the
adverse effects of fopen(log_file, "a") potetialy being called at the
same time and trying to open the same file. Is the file locked when
fopen(log_file, "a") is used?

The following is from the man page of fopen ( on Solaris 9 )
------------------------------------------------------
Opening a file with append mode (a as the first character in
the mode argument) causes all subsequent writes to the file
to be forced to the then current end-of-file, regardless of
intervening calls to fseek(3C). If two separate processes
open the same file for append, each process may write freely
to the file without fear of destroying output being written
by the other. The output from the two processes will be
intermixed in the file in the order in which it is written.

 

[Kevin Goodsell]

The following is from the man page of fopen ( on Solaris 9 )
------------------------------------------------------
Opening a file with append mode (a as the first character in
the mode argument) causes all subsequent writes to the file
to be forced to the then current end-of-file, regardless of
intervening calls to fseek(3C). If two separate processes
open the same file for append, each process may write freely
to the file without fear of destroying output being written
by the other. The output from the two processes will be
intermixed in the file in the order in which it is written.

OK, but that's hardly relevant to *standard* C (the only topic here),
where multiple processes are not defined. It's only relevant to Solaris
9, which may not be what the OP is using.

The standard answer is that the C definition assumes there is only a
single thread of execution, so it never defines what happens when two
things happen "at the same time". You have to consult your
implementation's documentation, and what it says is off-topic here.

-Kevin

 

[Derk Gwen]

(e-mail address removed) (Arturo Ordaz) wrote:
# Has anyone run into documentation that describes how fopen(log_file,
# "a") behaves when it is potentialy used (called/referenced) 1000's of
# times an hour on a single resource file? I am trying to find out the
# adverse effects of fopen(log_file, "a") potetialy being called at the

Operating system specific. Some might keep enough of the file system in
memory that there's little overhead. Others might have to crank out the
disk arm everytime.

# same time and trying to open the same file. Is the file locked when
# fopen(log_file, "a") is used?

Unless your operating system says opens are exclusive, you should take
responsibility for serialisation.

 

[Peter Nilsson]

OK, but that's hardly relevant to *standard* C (the only topic here),
where multiple processes are not defined. It's only relevant to Solaris
9, which may not be what the OP is using.

The standard answer is that the C definition assumes there is only a
single thread of execution, so it never defines what happens when two
things happen "at the same time". You have to consult your
implementation's documentation, and what it says is off-topic here.

The standard provides other assurances as far as reading back
information which was written. This would seem to make the above
quoted implementation potentially broken (if it claims conformance).

 

[Jack Klein]

The standard provides other assurances as far as reading back
information which was written. This would seem to make the above
quoted implementation potentially broken (if it claims conformance).

Indeed the standard does, but nowhere does it specify that such a
guarantee is true if anything other than the individual executable
modifies the file. And that includes another instance running
concurrently, which is something not defined at all by the C standard.