At 02:50 PM 4/13/2006, Alan Cox wrote:
The only serious case historically has been O_APPEND which does have
pretty precise semantics. Nowdays we also have pread/pwrite which have
pretty clear semantics and deal with threading. The O_APPEND case is
very important to get correct and 2.4 certainly did so.
...
As such I belive that the O_APPEND case must be kept locked properly and
the non O_APPEND cases are already correctly handled by the kernel. That
seems to argue for f_pos serialization on O_APPEND only.
I agree that O_APPEND is important to get correct. However, would that also
handle the specific case of stdout redirection to a file? (ie "a.out >
result", not just "a.out >> result" - the latter incidentally does not
currently seem to fail, at least with my tests)
Looking at the spec it says the following
"If the O_APPEND flag of the file status flags is set, the file offset
shall be set to the end of the file prior to each write and no
intervening file modification operation shall occur between changing the
file offset and the write operation."
This is what 2.4 took great paints to guarantee for file writes. Now in
actual fact no OS I know of implements this to the extreme (mmap) but
does for the other cases.
Outside of O_APPEND the specification says only that
- The write starts at the file position
- The file position is updated before the syscall returns
It makes no other guarantee I can see.
The POSIX 1003.1-2001 spec seems to provide a very clear guarantee of
thread-safety behavior wrt threads:
2.9.1 Thread-Safety
All functions defined by this volume of IEEE Std 1003.1-2001 shall be
thread-safe, except that the following functions need not be thread-safe.
<omitted list of functions, which does not include write>
Implementations shall provide internal synchronization as necessary in order
to satisfy this
requirement.
...
2.9.7 Thread Interactions with Regular File Operations
All of the functions chmod( ), close( ), fchmod( ), fcntl( ), fstat( ),
ftruncate( ), lseek( ), open( ), read( ), readlink( ), stat( ), symlink( ),
and write( ) shall be atomic with respect to each other in the effects
specified in IEEE Std 1003.1-2001 when they operate on regular files. If two
threads each call one of these functions, each call shall either see all of
the specified effects of the other call, or none of them.
Unless I'm missing something, that doesn't leave much ambiguity regarding
what's required for POSIX compliance on this issue (although I'm not sure
POSIX compliance is the right metric).
Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
