Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 (Tek) 9/12/84; site daemon.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!tektronix!daemon!davest From: davest@daemon.UUCP (Dave Stewart) Newsgroups: net.news.b Subject: Re: 'Cannot install' during expire Message-ID: <27@daemon.UUCP> Date: Thu, 1-Nov-84 14:32:33 EST Article-I.D.: daemon.27 Posted: Thu Nov 1 14:32:33 1984 Date-Received: Sat, 3-Nov-84 08:08:53 EST References: <413@uwmacc.UUCP> Reply-To: davest@daemon.UUCP (Dave Stewart) Distribution: net Organization: Tektronix, Beaverton OR Lines: 24 Summary: inews and expire should share a lock In article <413@uwmacc.UUCP> bllklly@uwmacc writes: >We've had some trouble with expire interfering with inews >... Not suprising, I guess, since >expire is rewriting the history. > >So is there are recommended way of keeping expire and inews >from interfering? Not only is expire mucking with the history file, but it's also rebuilding the active file. In either case, determinancy is lost since these are asynchronous processes writing to the same location. This is indeed a problem and one that should be looked at. One solution would be to put the same locking code that is in inews into expire. Or one might try some independant locking mechanism, such as uucp uses. A solution I like is for the processes to put an exclusive lock on the inode for the active and/or history files, such as the flock() system call in 4.2BSD. I realize that not everyone runs 4.2, but a kernel-level advisory locking scheme is something that all versions of Unix need for situations just like this. (Just stick to the facts, sir) Sorry! I got carried away ... -- David C. Stewart uucp: tektronix!davest Small Systems Support Group tektronix!usenet Tektronix, Inc. phone: (503) 627-5418