Messages in this thread |  | | | Date | Fri, 06 Feb 2004 09:26:36 +0000 | | From | Matt <> | | Subject | Re: VFS locking: f_pos thread-safe ? |
| |
Andrew Morton wrote:
>Matt <dirtbird@ntlworld.com> wrote: > > >>>Werner Almesberger <wa@almesberger.net> 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()? >> >> > >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? > > > > touché :) but still we should do what we can.. want me to make a patch?
Matt
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |