dclemans%UUCP@mntgfx.UUCP.UUCP (07/15/86)
We have the USENET news software (news 2.10.3 beta, rn, vn) running on the Apollo ring at Mentor Graphics. The news message directories (i.e., /usr/spool/news renamed) are on a DSP160. That same node also handles sending/receiving news from our feed site, sequent. People run the news reading programs from their individual nodes. In this environment, the BIG problem with the USENET software (specifically inews) is that it depends on being able to write to the news active file (and the history file?) anytime it wants to. This capability is NOT supported in general on a multi node Domain/IX environment; i.e. if a news reading program has the "active" file open for reading, inews/rnews WILL NOT be able to open it with write access (unless both the news reader program and inews/rnews are running on the same node). This causes things like multitudes of "unwritable files" messages to the news administrator, some articles dropped on the floor, etc. EXCEPT for "rn", things aren't too bad, because most of the news reader programs just read the active file once, close it (or else don't use it any more), and go on with their business. However, "rn" keeps the active file open and in use during the whole time it's running. This can lock out inews/rnews for quite a while. To get around this, I modified "rn" to make a copy of the active file when it starts up and from then on reference only the copy. I also stuck some "ulkob -f" (or equivalents) in at various places. With this there's still spurts when a few articles disappear, but it's not too bad. Another problem is that there are scattered uses of uninitialized local variables throughout the USENET software. While you can get away with that most of the time on typical UNIX architectures with entirely separate address spaces, you can't on Domain/IX where an address space is shared. dgc
mishkin@apollo.UUCP (Nathaniel Mishkin) (07/23/86)
In-Reply-To: decvax!tektronix!sequent!mntgfx!dclemans@yale.UUCP, mon, 14 jul 86 18:06:33
We have the USENET news software (news 2.10.3 beta, rn, vn) running
on the Apollo ring at Mentor Graphics....
In this environment, the BIG problem with the USENET software
(specifically inews) is that it depends on being able to write to
the news active file (and the history file?) anytime it wants to.
This capability is NOT supported in general on a multi node Domain/IX
environment; i.e. if a news reading program has the "active" file
open for reading, inews/rnews WILL NOT be able to open it with write
access (unless both the news reader program and inews/rnews are running
on the same node).
Another message has dealt (or will deal) with how to get around this
problem. I just want to point out that the reason that this facility
is not available is because it is fundamentally difficult to implement
with any guarantee of reasonable behavior. It's hard enough to implement
systems (and write programs that use) a facility that allows simultaneous
readers and writers of a single file on a single system, but when you
have multiple systems that don't even have a common physical memory,
it's nearly impossible.
In addition to the simultaneous readers and writers problem, "transient
file system failures" (e.g. network partitions that makes some file
temporarily unavailable) also screw up "traditionally written" programs.
(E.g. pieces of UUCP have the potential for serious problems if they're
not run on the node on which "/usr/spool/uucp" and "/usr/lib/uucp" actually
reside.)
These problems really demand more abstract solutions. E.g. in the case
of the Usenet sofware, there should be servers answering requests about
what the state of the active newsgroups are. Of course, the Usenet
software, along with tons of other Unix software, was developed before
there were distributed file systems so the need didn't seem pressing
at the time.
To get around this, I modified "rn" to make a copy of the active
file when it starts up and from then on reference only the copy.
I also stuck some "ulkob -f" (or equivalents) in at various places.
With this there's still spurts when a few articles disappear, but
it's not too bad.
"ulkob -f" is a power tool. Use it incorrectly and you could get hurt.
I'd like to know why/where you found it necessary to use it.
Another problem is that there are scattered uses of uninitialized
local variables throughout the USENET software. While you can get
away with that most of the time on typical UNIX architectures with
entirely separate address spaces, you can't on Domain/IX where an
address space is shared.
While our architecture may not be identical to vanilla Unix, it seems
clear to me that depending on the initial values of uninitialized local
variables is treading on thin (or no) ice. I.e. I think this qualifies
as a Usenet software bug.
-- Nat Mishkin
Apollo Computer Inc.
apollo!mishkin
-------