dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (08/29/90)
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 <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
merlyn@iwarp.intel.com (Randal Schwartz) (08/29/90)
In article <2320@cirrusl.UUCP>, dhesi%cirrusl (Rahul Dhesi) writes: | But if the host name in | the lock file is that of a different host, we refuse to supersede the | lock. This is incomplete. You might as well *never* supersede a lock with this scheme. What if "different host" has crashed? Isn't the proper solution something like lockf? Or is that a BSD-ism, or shunned by those in-the-know? (It wasn't in the One True Unix, so I can't make any comments on how used and useful it is.) | I recommend this locking scheme in place of the usual pid-only lock | file for all software, not just rn and nn. Why? You've jumped overboard and still haven't solved the problem of water leaking into the boat. :-) Just another puzzled Unix hacker and news reader, -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Welcome to Portland, Oregon, home of the California Raisins!"=/
mf@ircam.ircam.fr (Michel Fingerhut) (08/29/90)
Randal Schwartz writes: >Isn't the proper solution something like lockf? Or is that a BSD-ism [...] Unfortunately it (lockf) may be a BSD-ism, but not common to all BSD systems. I tried using it on a local network of 4.3BSD+NFS, SunOS3.5 and Ultrix3.0, all BSD or derived from it, and claiming to have lockf. While the 4.3 and Sun could lock each other correctly, Ultrix did not. Nor could it be locked. But then... should one be surprized?
cpcahil@virtech.uucp (Conor P. Cahill) (08/29/90)
In article <2320@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >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. But if you allow both processes to run on different hosts, you need to modify the other parts of rn that deal with the .newsrc and other related status/setup files. You will run into real problems when two processes try to write out different .newsrc files. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
guy@auspex.auspex.com (Guy Harris) (09/01/90)
>Unfortunately it (lockf) may be a BSD-ism, but not common to all BSD systems.
That's because it *isn't* a BSD-ism....