From owner-freebsd-hackers Fri Nov 28 05:46:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA13623 for hackers-outgoing; Fri, 28 Nov 1997 05:46:58 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ren.dtir.qld.gov.au (firewall-user@ns.dtir.qld.gov.au [203.108.138.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA13618 for ; Fri, 28 Nov 1997 05:46:53 -0800 (PST) (envelope-from syssgm@dtir.qld.gov.au) Received: by ren.dtir.qld.gov.au; id XAA05329; Fri, 28 Nov 1997 23:47:15 +1000 (EST) Received: from ogre.dtir.qld.gov.au(167.123.8.3) by ren.dtir.qld.gov.au via smap (3.2) id xma005327; Fri, 28 Nov 97 23:47:05 +1000 Received: from localhost.dtir.qld.gov.au (localhost.dtir.qld.gov.au [127.0.0.1]) by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with SMTP id XAA01518; Fri, 28 Nov 1997 23:46:58 +1000 (EST) Message-Id: <199711281346.XAA01518@ogre.dtir.qld.gov.au> X-Authentication-Warning: ogre.dtir.qld.gov.au: localhost.dtir.qld.gov.au [127.0.0.1] didn't use HELO protocol To: freebsd-hackers@freebsd.org cc: syssgm@dtir.qld.gov.au Subject: Re: flock() question References: In-Reply-To: from Marc Slemko at "Fri, 28 Nov 1997 06:51:22 +0000" Date: Fri, 28 Nov 1997 23:46:57 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Friday, 28th November 1997, Marc Slemko wrote: >On Thu, 27 Nov 1997, Charles Mott wrote: > >Locking works fine. It just doesn't do what you think it does. > >> guessed that locking would have worked in both situations. I am running >> 2.2.2-R. > >from the man page: > > Locks are on files, not file descriptors. That is, file descriptors du- > plicated through dup(2) or fork(2) do not result in multiple instances of > a lock, but rather multiple references to a single lock. If a process > holding a lock on a file forks and the child explicitly unlocks the file, > the parent will lose its lock. It's not entirely obvious from this that 1) your own exclusive lock will not prevent you from trying to assert an exclusive lock and 2) you are identified by your file table entry. In other words, you can lock the same file over and over and it doesn't nest. And you and your child are the same locker because you refer to the same file table entry. This is the mechanism in action in the first example program. It's so obscure that I think a manpage rewrite is in order, probably with some sample usage. For example, locks don't really apply to "files" (ie dev/inode) but to "file table entries" (ie channels to files), so an example that opens the same file twice and attempts to lock both file descriptors would deadlock. A few of these should scare most people off. :-) Please beat me to this rewrite. Otherwise it goes on my list. Bit dusty that list, but if the "rellies" leave me alone this Christmas we might see some action. :-) Stephen.