Matt <dirtbird@xxxxxxxxxxxx> wrote:touché :) but still we should do what we can.. want me to make a patch?
Werner Almesberger <wa@xxxxxxxxxxxxxxx> wrote:Surely, we can just serialise read() (and related) calls that modify f_pos?
"[...] read( ) [...] shall be atomic with respect to each otherWhichever thread finishes its read last gets to update f_pos.
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."
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().
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()?
We could do somethnig like that.
But is there any application in which two threads simultaneously perform
read() against the same fd which is not already buggy?