On Fri, Jan 03, 2014 at 04:12:37PM +0100, Kjetil Torgrim Homme wrote: > > Welcome to POSIX/Linux locking... read nice Lennart's summary: > > http://0pointer.de/blog/projects/locking.html > > http://0pointer.de/blog/projects/locking2 > > thanks! doesn't seem relevant for flock(1), though, since there is no > threading involved. flock(1) should acquire the lock, fork the child and > wait for it before returning the lock. no pitfalls there? ( flock -n 9 || exit 1 # ... commands executed under lock ... ) 9>/var/lock/mylockfile this is way how people use flock in scripts and it works because it's based on file descriptors and independent on original process. > I don't see why you think fcntl(2) sucks more. see Lennart's summary, the problem is that the lock is based on process and it's useless for system files (due to open/close in libraries), etc. > > No please, flock(1) is based on flock(2), that's all. The semantic > > and all possible limitations are well known. I don't think we want to > > make things more complicated. > > do you think we should have a posixlock(1)? (if so, perhaps it would fit > better in coreutils rather than util-linux ...) Yep. Frankly, reliable fcntl locking requires a lot of code and extra lock files (we use it for example in original mount for /etc/mtab). Karel -- Karel Zak <kzak@xxxxxxxxxx> http://karelzak.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
