[1652] in SIPB bug reports
GRIPE about XRN 6.14 (beta)
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Sun Feb 3 19:32:42 1991
Date: Sun, 3 Feb 91 19:32:15 -0500
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: boaz@concerto.lcs.mit.edu
Cc: bug-sipb@ATHENA.MIT.EDU
In-Reply-To: Boaz Ben-Zvi's message of Thu, 31 Jan 91 14:16:37 EST <9101311916.AA16619@concerto.lcs.mit.edu>
Date: Thu, 31 Jan 91 14:16:37 EST
From: boaz@concerto.lcs.mit.edu (Boaz Ben-Zvi)
This is both a gripe and a suggestion: Many times when XRN communicates
with the NNTP server, it (XRN) hangs until the server replies.
The worst cases I encountered were (occasionally) when I posted something:
after hitting the YES button on the dialog box (i.e. send the message) my
XRN hanged forever (I ended killing my XRN; but the message was indeed sent).
Note that this may be a separate bug.
This should not be happening anymore.
The way our news server used to be set up, attempts to post message
waited to be run with all the incoming news feeds; in addition, there
was no queuing, so every time the news system unlocked, the first
process to grab it got control of it. Since some news feeds take as
much as a half hour or more to deliver all their news, you could end
up waiting for a message to finish posting literally for hours if you
tried to post at a busy time of day.
However, we have recently modified the software so that posting
happens in a different queue from incoming news feeds, so posting
should never take you more than a minute. If it does, then the server
is hung or something.
My suggestion: whenever XRN communicates with the server, it should use
non-blocking calls and if not returning within a short period then give
the user information (e.g. "waiting for server" or "trying again") and
an option to abort (like the one for a long search).
Many of the calls already do this. If you end up waiting a long time
for something to happen, in the vast majority of cases, it's because
the operation you are performing really *takes* a long time to happen.
Adding non-blocking IO and stuff like that for the small number of
situations in which it would be useful would be an unnecessary
complication of the xrn code; I would not recommend it.
--> Jonathan Kamens
Project Athena Watchmaker and User Consultant
Student Information Processing Board (SIPB) member
jik@Athena.MIT.EDU
