thomson (12/15/82)
We at utcsrgv are somewhat alarmed at the amount of cpu eaten by
readnews ( @(#) defs.h 2.9 6/26/82 ). Most of this time is spent in kernel
state doing stat() and access() calls. On investigation, I have found
that:
1) readnews does a stat() of the .file for every newsgroup enabled
by the options line of your .newsrc file, whether or not you
are really subscribed to it. Most people here have an all-
inclusive options line and de-subscribe with the 'u' command,
so readnews checks every group there is.
2) if you do subscribe to group 'burp', readnews msgs interface
first does a stat() of /usr/spool/news/.burp and then an access() on
/usr/spool/news/burp/-1 . Other, more reasonable, access()
calls follow if there are any unread articles.
Before delving in to fix these (and make it that much harder to follow
distributed upgrades) I want to know if I'm missing anything.
I assume the extra stat() calls are really a bug. What about the
access() on message -1? It does let you manually insert a message with
that article number that will be displayed every time someone reads
group 'burp' -- was that intentional??
Also, why do an access() at all? It would seem sufficient to simply
let the fopen() fail. The only use I see is if readnews were a setuid
program, which it is not. Remember, those spool directories are large,
and if you have fifty users a day reading news every eliminated path
resolution helps.
Please mail or post replies, whichever you feel is more appropriate.
Brian Thomson
utcsrgv!thomsonmark (12/15/82)
The maintainers of B news are aware of the extra stat problem. This is why readnews is so slow in between newsgroups. The problem has already been fixed and the fix will be in 2.10. Current guesses for 2.10 release date are for early January.