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