Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!vsi1!lmb
From: lmb@vicom.COM (Larry Blair)
Newsgroups: news.software.b
Subject: Re: Comments on C news
Message-ID: <2293@vicom.COM>
Date: 23 Jun 89 00:11:01 GMT
References: <2228@vicom.COM> <1989Jun20.211939.7835@utzoo.uucp> <2277@vicom.COM> <1989Jun22.174603.10483@utzoo.uucp>
Reply-To: lmb@vicom.COM (Larry Blair)
Organization: VICOM Systems Inc., San Jose, CA
Lines: 34

In article <1989Jun22.174603.10483@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
=In article <2277@vicom.COM> lmb@vicom.COM (Larry Blair) writes:
=>
=>I'd like a combination of both.  Would an rews.immed with "newspool -i &"
=>work?  Actually, how about a daemon that stats the news spool directory
=>every minute?
=
=Uh, why?  Either you run newsrun periodically, or you ask newsspool to run
=it every time a batch comes in.  Or both.  I don't see the utility of the
="&", which will foul up trouble reporting.  And I don't see any point to
=checking every minute, which can in any case be achieved by running newsrun
=frequently.

The reason I'd like to background the newsspool (actually, the newsrun) is
so that my UUXQT will be able to go on to the next X. file without waiting
for the whole batch to be unbatched.  I'm worried about what happens if I
background it, though; it is reading the parent's stdin.

As far a as running newsrun every minute, that would use several orders of
magnitude more cpu than just stat'ing the directory.  I intend to implement
this sort of daemon.

=Do remember that duplicate articles are normal in some situations; for
=example, Toronto deliberately has redundant feeds, which means duplicates,
=in quantity, are to be expected.  The log does report which neighbor they
=came from; our experience is that information back beyond that is seldom
=useful (and it's very bulky).

We have 4 full feeds.  Every one of those feeds has an exclusion on what
they feed to us for some of the sites upstream from them.  The South Bay
is a veritable rat's nest of crossfeeds.  The way that we are all able to
determine what to exclude is from the log.
-- 
Larry Blair   ames!vsi1!lmb   lmb@vicom.com