From owner-freebsd-hackers Thu Dec 10 14:28:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA29623 for freebsd-hackers-outgoing; Thu, 10 Dec 1998 14:28:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA29615 for ; Thu, 10 Dec 1998 14:28:49 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id RAA46180; Thu, 10 Dec 1998 17:32:35 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Thu, 10 Dec 1998 17:32:35 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Marc Slemko cc: "Richard Seaman, Jr." , "hackers@freebsd.org" Subject: Re: pread/pwrite In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 10 Dec 1998, Marc Slemko wrote: > On Thu, 10 Dec 1998, Richard Seaman, Jr. wrote: > > > I don't know if there is any interest in X/Open pread, pwrite > > calls. Essentially, they implement atomic seek/write and > > atomic seek/read calls. They are more useful in threaded > > apps where you would need a file lock between a seek/write > > or seek/read, but even in single threaded apps can allow > > you to avoid a syscall. > > > > Attached is an implementation. If there is interest, and > > if the implementation meets with approval, I'll submit > > a PR. Or, perhaps someone would want to commit it directly. > > > > I welcome any comments. > > (not necessarily addressed specifically at pread/pwrite, but it does > apply to it because of how it is used...) > > Where is the locking if multiple threads are reading and/or writing > from or to the same descriptor at the same time? If you have x > threads reading from a descriptor opened from a file on disk, do > x-1 of them have to wait until the first one finishes before they can > do anything? > > What about with mixed reading/writing? >From looking at the diffs what I think what he implemented was a seek+(write|read) in one syscall. Meaning you do not have to lock an fd when seeking and then writing since it's one syscall it's atomic. This saves on syscalls in general, and helps thread coders save on locking overhead. (Basically if you plan to seek, then read/write, unless you lock on the fd, you risk another thread moving the file pointer out from under you.) plus... solaris and IRIX have it, we should too, doncha think? Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com -- There are operating systems, and then there's FreeBSD. -- http://www.freebsd.org/ 3.0-current To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message