This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: fcntl and flockfile man pages
Daniel Jacobowitz wrote:
On Wed, Oct 24, 2007 at 11:25:33AM -0400, Jairo19@interhosting.us wrote:
Hola:
I was reading the fcntl man page on my Fedora 7(up to date) installation and
saw the following comment:
"
Because of the buffering performed by the stdio(3) library, the use
of record locking
with routines in that package should be avoided; use read(2) and write(2)
instead.
"
But then looking at the flockfile man page I see it states that stdio
functions are thread safe, which may imply that record locking gives you
nothing when used.
No. Record locks are for more than just threads in the same process;
they work between processes. Stdio buffering is within one file.
Daniel, thanks for your quick answer.
I see, I started investigating this because my code was locking the file
with fcntl(), and then writing with fputs(3), but then I found the fcntl
man page says I should avoid that. So, in this case is the stdio
buffering really affecting the synchronized write access to the file
from threads and other processes ?
Also, I do not see anything that tells me if flockfile() creates mandatory
locks (is it implied ?).
(Note: this locking has nothing to do with the file locking
done by functions like flock(2) and lockf(3).)
It seems, I can neither use flock(2) because it is not mandatory, nor
lockf(3) because it is not portable. So I'm down to fcntl again, but I
have to replace fputs(3) with write(2), which is not thread-safe per se.
Does this sound right ?
flockfile is locking the FILE object, not the underlying file.
is it worth changing the flockfile man page from:
"flockfile, ftrylockfile, funlockfile - lock FILE for stdio"
to
"flockfile, ftrylockfile, funlockfile - lock the FILE object for stdio
(not the underlying file)"
?
Regards.