Date: 13 Apr 1999 10:34:24 +0300 From: Ville-Pertti Keinonen <will@iki.fi> To: narvi@haldjas.folklore.ee (Narvi) Cc: hackers@freebsd.org Subject: Re: read() and pread() syscalls Message-ID: <861zhp2cu7.fsf@not.demophon.com> In-Reply-To: narvi@haldjas.folklore.ee's message of "13 Apr 1999 10:10:40 %2B0300" References: <86hfqmgcoh.fsf@not.demophon.com> <Pine.BSF.3.96.990413095554.13437M-100000@haldjas.folklore.ee>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?861zhp2cu7.fsf>