Path: utzoo!utstat!helios.physics.utoronto.ca!jarvis.csri.toronto.edu!rutgers!psuvax1!brutus.cs.uiuc.edu!usc!elroy.jpl.nasa.gov!jato!herron.uucp!jbrown
From: jbrown@herron.uucp (Jordan Brown)
Newsgroups: news.software.b
Subject: Re: C News patch of 10-Jan-1990
Message-ID: <232@herron.uucp>
Date: 15 Jan 90 21:28:40 GMT
References: <1990Jan11.000427.29455@utzoo.uucp> <75308@looking.on.ca>
Reply-To: jbrown@jato.jpl.nasa.gov
Lines: 26

In article <75308@looking.on.ca>, brad@looking.on.ca (Brad Templeton) writes:
> [clarinet groups often have big holes]
> RN has code to deliberately sleep for 1.3 seconds when it finds such a hole,
> which makes an annoying delay.  Never bothered me much on my fast console,
> but it's a big pain when using RRN, which considers the holes as
> 'unreadable articles'

This is a bug in RRN.  I've sent a patch to Stan Barber that fixes it.
The problem is that the higher-level code that doesn't know it's RRN
expects errno to reflect the cause of the error.  The low-level RN
code leaves it set properly (or rather, open does), but the RRN code
doesn't.  The high-level code sees a reported error, but since errno
isn't ENOENT, it assumes that something wierd is going on and so sleeps
so you can see it.  My patch makes the low-level RRN code set errno
to ENOENT when the problem occurs.

Unfortunately, the code is on another machine do I can't just post a diff.
I believe it was in artio.c that I added a simple "errno = ENOENT;".

The result is an enormous improvement in RRN performance in the face
of holes.  (Another big source is "Welcome to XXX" messages with expires:
headers that keep them around long after you've tossed articles after
them.)
-- 
Jordan Brown
jbrown@jato.jpl.nasa.gov