f_offset

[Ed Schouten]

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.

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.

-- 
 Ed Schouten <ed at 80386.nl>
 WWW: http://g-rave.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080414/e3d05c34/attachment.pgp