Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!decvax!seismo!rick
From: rick@seismo.UUCP
Newsgroups: news.software.b
Subject: Re: SPOOLNEWS/locking question
Message-ID: <43880@beno.seismo.CSS.GOV>
Date: Tue, 26-May-87 18:05:11 EDT
Article-I.D.: beno.43880
Posted: Tue May 26 18:05:11 1987
Date-Received: Wed, 27-May-87 05:17:11 EDT
References: <1943@ihuxv.ATT.COM>
Organization: Center for Seismic Studies, Arlington, VA
Lines: 24
Keywords: rnews SPOOLNEWS
Summary: The locking gospel...

Here is my interpretation of what is locking what and why.

First, when expire is running, EVERYTHING else stops. This includes
rnews -U. inews/rnews spool for later dequeueing by rnews -U. When
expire is done, it fires up rnews -U which unspools the files that were
spooled because expire was running.

rnews -U just reads the spool directory (.rnews) and executes rnews -S
for each file in the directory. There is a lockfile to prevent multiple
rnews -U from running. However, there is no reason (planned anyway.
There is always the possibility of another bug.) for one rnews -S to knock
another one out of action.

I think that what is happening is the expire is running during one of
your queue runs, so the queue run (correctly in my opinion) is being
aborted early.

Note that rnews only sets a READ lock (unless you have a broken
implementation of advisory locks, which System 5 does not), so 2 rnews
programs should not be able to get in each others way.

Expire sets a WRITE lock, so the rnews read locks should fail.

---rick