f_offset

[Jeff Roberson]

On Mon, 14 Apr 2008, Ed Schouten wrote:

> Hello Jeff,
>
> * Jeff Roberson <jroberson at jroberson.net> wrote:
>> Concurrent calls to read() are inherently racy.  They will still use the
>> current value of f_offset and store it while they are done.
>
> I'm experiencing similar problems with implementing read() and write()
> inside my mpsafetty branch for TTY's. Just like the current TTY
> implementation, my implementation will do strange things when two
> threads call read() or write() at the same time. Data could end up mixed
> together. The main cause is that mutexes cannot be held when copying
> data back to userspace, which is obvious.

You should use an sx lock which can be held across such operations.  Non 
seekable devices, terminals included, have to serialize all IO.  They are 
treated separately by posix.

>
> I could store flags to indicate a read() or write() call is in progress,
> but because there is no requirement for this, I think I won't pay
> attention to this.
>
> With regular files you could probably increment the offset before
> copying any data back to userspace, but of course those calls may fail
> (EFAULT, EIO), which means the offset shouldn't advance.

Right this offset can't be visible to other threads until the operation 
completes successfully.

Jeff

>
> -- 
> Ed Schouten <ed at 80386.nl>
> WWW: http://g-rave.nl/
>