Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 +SENDMAIL+2.11; site dcl-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!mcvax!ukc!dcl-cs!stephen
From: stephen@dcl-cs.UUCP (Stephen J. Muir)
Newsgroups: net.news.b,net.news.adm
Subject: How I would like race conditions avoided (rnews/inews/expire).
Message-ID: <869@dcl-cs.UUCP>
Date: Sun, 15-Dec-85 16:14:17 EST
Article-I.D.: dcl-cs.869
Posted: Sun Dec 15 16:14:17 1985
Date-Received: Tue, 17-Dec-85 07:27:39 EST
Expires: Sun, 30-Mar-86 19:00:00 EST
Reply-To: stephen@comp.lancs.ac.uk (Stephen J. Muir)
Organization: Department of Computing at Lancaster University.
Lines: 19
Xref: watmath net.news.b:1280 net.news.adm:464

I think that "inews", "rnews" and "expire" should never run in combination with
themselves or each other (I know that "inews" and "rnews" are the same program
and that only one "expire" should be running anyway).

They should each apply an exclusive lock which applies to them all when they
start.  For "inews" and "rnews", they should queue their input/parameters
somehow and run a queue processing daemon which processes the articles/batches
one at a time (using the *same* exclusive lock).  It is necessary for "inews"
so that the user is not kept waiting and for "rnews" to help systems which
don't use UUCP as the news transport mechanism (like us) where the sending
machine, at present, has to wait until "rnews" completes!  (It will help UUCP
news transport system as well).  For "expire", it will just wait until it gains
the exclusive lock, then run to completion.
-- 
UUCP:	...!seismo!mcvax!ukc!dcl-cs!stephen
DARPA:	stephen%comp.lancs.ac.uk@ucl-cs	| Post: University of Lancaster,
JANET:	stephen@uk.ac.lancs.comp	|	Department of Computing,
Phone:	+44 524 65201 Ext. 4599		|	Bailrigg, Lancaster, UK.
Project:Alvey ECLIPSE Distribution	|	LA1 4YR