From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 01:20:43 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6767D16A4CE for ; Thu, 1 Jul 2004 01:20:43 +0000 (GMT) Received: from blitzen.qlo.com (blitzen.qlo.com [142.165.150.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C2D343D49 for ; Thu, 1 Jul 2004 01:20:43 +0000 (GMT) (envelope-from shurd@sasktel.net) Received: from stephens (hssx-yktn-59-202.sasknet.sk.ca [142.165.59.202]) by mail.qlo.com (SaskTel eMessaging Service) with ESMTPA id <0I0500JFWFQH1E@mail.qlo.com> for freebsd-hackers@freebsd.org; Wed, 30 Jun 2004 19:20:42 -0600 (CST) Date: Wed, 30 Jun 2004 19:20:41 -0600 From: Stephen Hurd In-reply-to: <20040628192935.GF5635@green.homeunix.org> To: freebsd-hackers@freebsd.org Message-id: <20040630192041.1d9c5348.shurd@sasktel.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20040624174919.46160f9e.shurd@sasktel.net> <20040628192935.GF5635@green.homeunix.org> Subject: Re: Locking: kern/50827 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2004 01:20:43 -0000 > > Has anyone looked at this? Does anyone have any comments? > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/50827 > > I don't think you'll ever find anyone interested in file locking > anymore. Since they're all advisory, anyway, you can just implement them > at a higher level in your application. BSD and System V IPC mechanisms > already are very good building blocks here for system-scoped locks. Hrm? I'm sort of confused... file locking is still the best way of doing erm... file locking. A few points: 1) File locking works with any program using the file locking API. Hand-rolled implementations will only work with other programs which use the same hand-rolled routines. 2) File locking works across NFS, so you aren't limited to the local system. 3) There's no simple way of doing per-descriptor locks using BSD and SysV IPC... ie: locks which are automatically released when the file descriptor used to obtain the lock is released. This also of course means programs which core won't leave stale locks laying around. Essentially, implementing locks at a higher level is alway more difficult, usually more prone to problems, and in some cases introduces more overhead than the rest of the program. The only reason I can think of for implementing locks at a higher level is for cross-platform code...