From owner-freebsd-hackers Tue Apr 13 0:37: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (Postfix) with SMTP id 51FAE14CA9 for ; Tue, 13 Apr 1999 00:37:01 -0700 (PDT) (envelope-from will@ns.oeno.com) Received: (qmail 1761 invoked by uid 1001); 13 Apr 1999 07:34:39 -0000 To: narvi@haldjas.folklore.ee (Narvi) Cc: hackers@freebsd.org Subject: Re: read() and pread() syscalls References: <86hfqmgcoh.fsf@not.demophon.com> From: Ville-Pertti Keinonen Date: 13 Apr 1999 10:34:24 +0300 In-Reply-To: narvi@haldjas.folklore.ee's message of "13 Apr 1999 10:10:40 +0300" Message-ID: <861zhp2cu7.fsf@not.demophon.com> Lines: 32 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG narvi@haldjas.folklore.ee (Narvi) writes: > On 12 Apr 1999, Ville-Pertti Keinonen wrote: > > This may come as a shock to you, but read(2)/write(2) aren't atomic in > > updating the file pointer, either. > How come? I'm not sure whether the locking is supposed to prevent multiple simultaneous readers on a vnode (which would be silly), it certainly doesn't. Updating the pointer consistently over blocks without nasty locking operations is quite impossible the way things work now, the file descriptor object isn't available to the low-level I/O code. > > Actually, read(2) is equivalent to lseek(2)+pread(2)+lseek(2), with the > > last lseek(2) being SEEK_CUR by the read count returned by pread(2). > > The difference is that read(2) can only be pre-empted if it blocks > > doing I/O (which is not unusual). > I would like to hear where is the code that would back up your claims. Just follow the code path for file I/O operations. /sys/kern/vfs_vnops.c, grep for ^vn_read. > At least in 3.1 it is not so. I'm absolutely certain that it is. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message