Date: Mon, 14 Apr 2008 09:47:10 +0200 From: Ed Schouten <ed@80386.nl> To: Jeff Roberson <jroberson@jroberson.net> Cc: arch@freebsd.org Subject: Re: f_offset Message-ID: <20080414074710.GI5934@hoeg.nl> In-Reply-To: <20080413131724.X959@desktop> References: <1309.1208100178@critter.freebsd.dk> <20080413131724.X959@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
--w+rhPQc/K9ract27 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jeff, * Jeff Roberson <jroberson@jroberson.net> wrote: > Concurrent calls to read() are inherently racy. They will still use the= =20 > 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. --=20 Ed Schouten <ed@80386.nl> WWW: http://g-rave.nl/ --w+rhPQc/K9ract27 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkgDC/4ACgkQ52SDGA2eCwWwBACbBo/DheVrtSZtogASRWxCw9XS ic8An3qVDDDwk/lOzXNsaCCyfBie/w+8 =9SZf -----END PGP SIGNATURE----- --w+rhPQc/K9ract27--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080414074710.GI5934>