🚀 go-pugleaf

In <1992Dec21.145320.1065@blilly.UUCP> lilb@sony.compuserve.com (Bruce Lilly) writes:
I am not sure what the point of Bruce's article was.  It contained a disucssion
of VM, paging, performance trade-offs, etc.  I'll lift out the news-related
questions and answer as best as I can.

>  Due to a design decision, the per-process VM
>limit is 2.5 MB, regardless of how large the swap space is.  It certainly
>sounds like INN won't run on a 3B1.
Yes it does sound like that.  However, if you ran without dbzincore() it
will might work.  (And what a stupid design decision.)

>Not every system *has* a writev().
INN includes the obvious stupid emulation (turn writev into a series of
write calls), and some notes about how you have to be careful if you turn
it into the first-pass more efficient emulation (allocating one big buffer
and doing one write).  It works without writev, but you'll now be writing
an article in six syscalls rather than one, but it's still efficient.

>>> Does innd have to be running continuously, or can it be run on an
>>> as-required basis from inetd
It will not work.  First off, you'd have to hack the source a fair
amount.  More importantly, A single innd wants ALL incoming connections;
running out of inetd means multiple innds when multiple feeds connect,
and that is very bad.  You could add a "wait" in your inetd.conf file,
but since innd doesn't exit after your first connection it would be just
as if you ran the proper configuration.

>Does INN *need* ``UNIX-domain'' sockets?
INN1.2 works without it, but it's a bit clunky:  people had to make some
patches.  In INN1.3 things are better:  they sent their diffs to me and I
included them in the mainline code.

> but it's wrong to assume that pipes will always yield
>performance better than disk files, for all systems.
The primary advantage of pipes is that they don't have to be written
out to backing store, hence performance gain.

Like other news software, INN can write batchfiles.  Since innd is a
long-running daemon, however, the ability to spawn a process and feed
the 'batchfile' on stdin was an obvious thing to do.