From owner-freebsd-current  Sun Nov  7  6:43:37 1999
Delivered-To: freebsd-current@freebsd.org
Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13])
	by hub.freebsd.org (Postfix) with ESMTP id C35C614C2D
	for <current@freebsd.org>; Sun,  7 Nov 1999 06:43:30 -0800 (PST)
	(envelope-from ben@scientia.demon.co.uk)
Received: from strontium.scientia.demon.co.uk ([192.168.0.4] ident=exim)
	by scientia.demon.co.uk with esmtp (Exim 3.092 #1)
	id 11kTIw-000IkO-00; Sun, 07 Nov 1999 14:28:26 +0000
Received: (from ben) by strontium.scientia.demon.co.uk (Exim 3.092 #1)
	id 11kTIw-0000Zt-00; Sun, 07 Nov 1999 14:28:26 +0000
Date: Sun, 7 Nov 1999 14:28:26 +0000
From: Ben Smithurst <ben@scientia.demon.co.uk>
To: David Malone <dwmalone@maths.tcd.ie>
Cc: current@freebsd.org
Subject: Re: Serious locking problem in CURRENT
Message-ID: <19991107142826.A2118@strontium.scientia.demon.co.uk>
References: <local.mail.freebsd-current/19991105225916.A14961@keltia.freenix.fr> <local.mail.freebsd-current/19991106005016.A865@keltia.freenix.fr> <local.mail.freebsd-current/19991106134548.A2921@walton.maths.tcd.ie> <199911061929.NAA26145@free.pcs> <19991107112458.A14670@walton.maths.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <19991107112458.A14670@walton.maths.tcd.ie>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

David Malone wrote:

> On Sat, Nov 06, 1999 at 01:29:16PM -0600, Jonathan Lemon wrote:
> 
>> From the manual page for flock:
>> 
>> NOTES
>>      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.
> 
> Doesn't this make it impossible to hold a lock on a file when you
> want to fork a child to do some task 'cos the lock will be dropped
> when the child closes its copy of the file discriptor on exit?
> Either it's a posix goof or the lock shouldn't be let go until
> either explicitly released or the last instance of the file discriptor
> is closed?

The lock doesn't seem to be released until *explicitly* released, like
the manual page says. I don't think closing the descriptor counts as
an explicit unlock, though I am probably wrong. Run this program,
you'll see the parent still has the lock. Change close(fd) to flock(fd,
LOCK_UN) and you'll see it doesn't. It's possible I've misunderstood
something though.

#include <fcntl.h>
#include <err.h>
#include <stdio.h>
#include <unistd.h>

int
main(void) {
	int fd;

	fd = open("lock", O_CREAT|O_RDWR, 0600);
	if (fd < 0)
		err(1, "open");

	if (flock(fd, LOCK_EX) != 0)
		err(1, "flock");

	switch (fork()) {
	case -1:
		err(1, "fork");
	case 0:
		close(fd);
		_exit(0);
	default:
		sleep(2);
		break;
	}

	system("lsof | less");
	return (0);
}

-- 
Ben Smithurst            | PGP: 0x99392F7D
ben@scientia.demon.co.uk |   key available from keyservers and
                         |   ben+pgp@scientia.demon.co.uk


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message