Date: Wed, 30 Jun 2004 19:20:41 -0600 From: Stephen Hurd <shurd@sasktel.net> To: freebsd-hackers@freebsd.org Subject: Re: Locking: kern/50827 Message-ID: <20040630192041.1d9c5348.shurd@sasktel.net> In-Reply-To: <20040628192935.GF5635@green.homeunix.org> References: <20040624174919.46160f9e.shurd@sasktel.net> <20040628192935.GF5635@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040630192041.1d9c5348.shurd>