Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!b-tech!zeeff
From: zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff)
Newsgroups: news.software.b
Subject: Re: NNTP vs Cnews (was: Re: Cnews is not for me)
Message-ID: <9640@b-tech.ann-arbor.mi.us>
Date: 21 Aug 89 14:41:44 GMT
References: <2828@ndsuvax.UUCP> <1989Aug12.221624.12153@utstat.uucp> <1894@ucsd.EDU> <1989Aug13.071802.5187@utzoo.uucp> <527@logicon.arpa> <9636@b-tech.ann-arbor.mi.us> <1989Aug16.182527.24840@utzoo.uucp>
Reply-To: zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff)
Organization: Branch Technology Ann Arbor, MI
Lines: 29

>>I came to the same conclusion.  Relaynews should just be sitting there all
>>all the time waiting for rnews to feed it something.

>You have to think about when caches get flushed:  other things rely on the
>disk being fairly up to date, and flushing everything out is a non-trivial
>part of the current startup/shutdown overhead.  And there are some thorny
>locking issues involved.  One aspect of it is quite fundamental:  there
>can only be one relaynews running at a time if file updating is to be
>done properly, and so you need a way to feed that process from multiple
>sources -- this is very hard to do portably.
>

The locking/concurrency problem is basically the same one that exists 
now.  You put a lock on input to relaynews that processes have to wait 
for if busy.  True, the IPC stuff isn't going to be very portable.

I agree about the cache flushing - but the big advantage is that you 
do things when needed (every n minutes or n articles), not 
automatically for every batch.  







-- 
Branch Technology            |  zeeff@b-tech.ann-arbor.mi.us
                             |  Ann Arbor, MI