Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!nuchat!sugar!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.unix.wizards Subject: Re: Is HDB locking safe? Message-ID: <+7C5OFD@xds13.ferranti.com> Date: 20 Aug 90 21:53:45 GMT References: <577@oglvee.UUCP> <4024@rtifs1.UUCP> <18500@rpp386.cactus.org> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 18 In article peter@ficc.ferranti.com (Peter da Silva) writes: > No sleep is ever enough. The system could simply be busier than you ever > imagined. You don't solve a race problem by narrowing the window: try > checking the return value of the "unlink": that's the point of failure. In article <18500@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: > There is a big, fat window between the kill() and the unlink() during > which time the other process and kill() the dead process, unlink() the > stale lock, and creat() the new lock file. Your process will then > unlink() a lock which has just be created. You're right. Can you suggest a locking protocol that would work here? I can't imagine that it could be made robust enough to survive a process crashing during the locking process, but it should be possible to handle most cases of programs crashing whle locked. I guess creating a second lock file to be held while deleting the first would work. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com (currently not working) peter@hackercorp.com