Re: VFS locking: f_pos thread-safe ?

[Matt]

> Werner Almesberger <wa@xxxxxxxxxxxxxxx> wrote:
> > "[...] read( ) [...] shall be atomic with respect to each other
> >   in the effects specified in IEEE Std. 1003.1-200x 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."

> Whichever thread finishes its read last gets to update f_pos.

> I'm struggling a bit to understand what they're calling for there.  If
> thread A enters a read and then shortly afterwards thread B enters the
> read, does thread B see an f_pos which starts out at the beginning of A's
> read, or the end of it?

> Similar questions apply as the threads exit their read()s.

> Either way, there's no way in which we should serialise concurrent readers.
> That would really suck for sensible apps which are using pread64().

Surely, we can just serialise read() (and related) calls that modify f_pos?
Since pread() doesn't modify f_pos we shouldn't need to serialise those calls
no? Also doesn't spec make the same claims about other calls that modify
f_pos such as write()?

	Matt





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/