Xref: utzoo news.software.nn:918 comp.unix.questions:25040 Path: utzoo!utstat!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!elroy.jpl.nasa.gov!jarthur!bridge2!3comvax!tymix!cirrusl!sungraph!dhesi From: dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) Newsgroups: news.software.nn,comp.unix.questions Subject: robust locking Message-ID: <2320@cirrusl.UUCP> Date: 28 Aug 90 18:40:05 GMT Sender: news@cirrusl.UUCP Lines: 27 Here is a suggestion about locking mechanisms. Both rn and nn assume that a user's home directory is available only on one host. This is not necessarily true if you have NFS. It has occasionally happened to me with rn that I had an rn session going on one host and started another on a different host on which I had the same NFS-mounted directory. The second rn, not finding the first rn's process, assumed it had crashed. I think nn, too, does not attempt to ensure that no nn is active for the same user on any host. A very simple mechanism can be used to ensure that such race conditions don't occur. Create a lock file that contains both process id and host name. If a second process wants to create the same lock, it checks any existing lock file. If the lock file exists, and the host name in it is that of the current host, then the process id in it can be tested to see if it is that of an existing process (and if not, that process crashed and the lock file can be superseded). But if the host name in the lock file is that of a different host, we refuse to supersede the lock. I recommend this locking scheme in place of the usual pid-only lock file for all software, not just rn and nn. -- Rahul Dhesi UUCP: oliveb!cirrusl!dhesi