Date: Sun, 4 Jul 2004 14:13:47 -0400 From: Brian Fundakowski Feldman <green@freebsd.org> To: Stephen Hurd <shurd@sasktel.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Locking: kern/50827 Message-ID: <20040704181347.GE997@green.homeunix.org> In-Reply-To: <20040630192041.1d9c5348.shurd@sasktel.net> References: <20040624174919.46160f9e.shurd@sasktel.net> <20040628192935.GF5635@green.homeunix.org> <20040630192041.1d9c5348.shurd@sasktel.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 30, 2004 at 07:20:41PM -0600, Stephen Hurd wrote: > > > 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... Right, if you just make it cross-platform in the first place using higher- level primitives you don't have to worry what the specific kernel and operating system and file system you are using provides. It's my opinion tha there won't be other people adopting this API for file locking since it is by definition not meant to work like the standardized APIs. I don't think that there's no value in having more useful locking primitives, but they probably don't benefit much from being implemented in the kernel unless they conform to a portable API. I certainly always have my own various kernel modifications that I find useful, but aren't very standard :) -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040704181347.GE997>