Date: Sun, 13 Apr 2008 22:32:01 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: Ed Schouten <ed@80386.nl> Cc: arch@freebsd.org Subject: Re: f_offset Message-ID: <20080413223053.U959@desktop> In-Reply-To: <20080414074710.GI5934@hoeg.nl> References: <1309.1208100178@critter.freebsd.dk> <20080413131724.X959@desktop> <20080414074710.GI5934@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 14 Apr 2008, Ed Schouten wrote: > Hello Jeff, > > * Jeff Roberson <jroberson@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@80386.nl> > WWW: http://g-rave.nl/ >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080413223053.U959>