lkml.org 
[lkml]   [2004]   [Feb]   [6]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 06 Feb 2004 09:26:36 +0000
FromMatt <>
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:00    [from the cache]
©2003-2008