Xref: utzoo comp.unix.microport:3971 news.software.b:4128
Newsgroups: comp.unix.microport,news.software.b
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Cnews ported to V/AT?
Message-ID: <1990Feb11.205307.18752@utzoo.uucp>
Organization: U of Toronto Zoology
References: <45@frau.UUCP> <3+1:A3-@splut.conmicro.com> <1990Feb8.182437.25095@utzoo.uucp> <T+4:TZ@splut.conmicro.com>
Date: Sun, 11 Feb 90 20:53:07 GMT

In article <T+4:TZ@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes:
>Well, they run...but they fail in the middle. Expire complains about
>running out of memory, sometimes saying that it's trying to read a line
>of history, sometimes not; relaynews simply fails mysteriously. My
>active file:
>-rw-rw-r--   1 usenet   news       20865 Feb 10 15:50 /usr/lib/news/active
>Not huge, but not trivial, either.

Big enough to be a bad sign, I'm afraid.  A 16-bit program only has 64KB
of data space, and it wants to use some of that for other things.

>Unfortunately, rebuilding just expire and relaynews in large model is
>such a pain that I haven't applied the January 1990 patches yet; I don't
>know if they'd fix the problem or not.

Probably not.  We haven't done anything lately that would cause a major
drop in memory requirements.  The prognosis isn't good, either.  One of
the things on my low-priority-to-do list for expire is a change that
would save a lot of memory on small machines, at the expense of rather
more CPU use, but there is no equivalent for relaynews that I know of.

(Expire keeps an in-core copy of its control file, but uses it only when
it runs across a hitherto-unknown newsgroup.  Normal decisions are made
based on a hash table with an entry per newsgroup.  With a big active
file, that hash table is big too.  It could be eliminated, if one were
sufficiently short of memory to accept doing a search of the control-file
structure every time.  Expire used to work that way, in fact; the hash
table is just an optimization.  Relaynews is a very different story,
and cutting memory use there would probably be nasty and complicated.
Barring some sudden inspiration about how to massively reduce memory
use with a ten-line change -- not likely! -- that probably won't happen.)
-- 
SVR4:  every feature you ever |     Henry Spencer at U of Toronto Zoology
wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu