Date: Sun, 13 Apr 2008 13:19:35 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@freebsd.org Subject: Re: f_offset Message-ID: <20080413131724.X959@desktop> In-Reply-To: <1309.1208100178@critter.freebsd.dk> References: <1309.1208100178@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 13 Apr 2008, Poul-Henning Kamp wrote: > In message <20080412221654.S959@desktop>, Jeff Roberson writes: > >>> The non p-prefix versions should always be serialized, because there >>> is know way of knowing where they read/write if you don't. >> >> Well that's at odds with what the standard says and what others implement. >> I think there is a clear case for serializing writes. I don't see what >> advantage we get from serializing reads. The heavy cost of >> synchronization should be justified by actual need. > > If you don't serialize read(2) and readv(2), how do you know where > they read from ? 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 just suggesting we don't use an exclusive lock that is held for the duration of the io to protect the update to the f_offset field. The field will still be updated in such a way that it is atomic. Thanks, Jeff > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080413131724.X959>