Re: VFS locking: f_pos thread-safe ?

[kaih@khms.westfalen.de (Kai Henningsen)]

smurf@smurf.noris.de (Matthias Urlichs)  wrote on 06.02.04 in <pan.2004.02.06.18.59.44.936432@smurf.noris.de>:

> Hi, viro wrote:
>
> > "Somebody made a guess about undefined behaviour"
>
> Guess what? The manpage says that read(2) return N bytes and advances the
> file pointer by N bytes. It doesn't talk, much less caution, about threads.

That's a defect in the man page, then.

POSIX says on <http://www.opengroup.org/onlinepubs/007904975/functions/ 
read.html>:

[...]
DESCRIPTION

The read() function shall attempt to read nbyte bytes from the file
associated with the open file descriptor, fildes, into the buffer pointed
to by buf. The behavior of multiple concurrent reads on the same pipe,
FIFO, or terminal device is unspecified.
[...]

That's a pretty explicit warning exactly where one would expect it.

If Linux read(2) doesn't say something like that, I'll consider that a  
serious bug.

OTOH ...

> YOU may immediately know, based on your kernel knowledge or whatever, that
> things get somewhat undefined when two threads do that at the same time,
> but it's NOT AT ALL obvious to a "normal" application programmer. There's
> plenty of system calls that CAN be done concurrently, after all.

... these days, programmers really *should* know enough to consult a free,  
current, and easily readable version of the relevant standard!

(If you forget where it is, it's easy to find from <http://www.unix- 
systems.org/>.)

> Please save your "translations" for stupid ideas that are obviously so
> without in-depth kernel knowledge or equivalent.

... such as the current case.

MfG Kai