[Pan-users] Re: Weird cache problem

[Duncan]

Jim Henderson posted on Fri, 28 Aug 2009 22:45:37 +0000 as excerpted:

> I've just added a second authenticated server to my 0.133 system, and
> since then, I've had an occasional seemingly random problem pop up.
> 
> The problem is that sometimes after reading a message and going to the
> next unread (either in the same group or in a new group), I end up with
> the cached copy of the article pointing to the last article I read.  If
> I go forward another new message, I get the new message, but going back
> Pan continues to read the incorrect cache file.
> 
> The only solution I've found so far is to exit and restart Pan (I'm
> configured to clear the cache on exit).
> 
> Anyone seen anything like this?

I've seen absolutely nothing like that here, multiple servers, but not 
multiple authenticated ones (one authenticated, some time ago, none for 
awhile tho).

Two observations:

One:  I /have/ seen occasional problems with posts that show no bodies at 
all.  From my troubleshooting, this almost always involves posts with 
some exotic non-ASCII character, say a UTF-8 no-wrap-blank-space (IDR for 
sure what the technical term for them is ATM, is that correct?, I just 
woke up and my mind is still coming back up to speed) or the like.

Pan is supposed to be able to handle that sort of thing, and the gtk+ 
text widget it uses is supposed to be fine with it, but apparently that's 
not always the case.  One of the problem chars was even in a quote of 
something I wrote in pan, but I suspect the other client supplied the 
nwbs or whatever it's called.

It's mighty irritating.  Often someone else quotes the offending blank 
post and I can see the quote just fine.  Otherwise, while I can't 
actually see the body in pan, saving the post as text still works, and 
it's from that I've done my debugging, opening that text in text editors 
or the like.  As I said, in every case, it's a non-ASCII char, in some 
cases an apparently valid UTF-8 or other char, in others, an entirely 
invalid one.

But I don't see how that's directly connected to the behavior you're 
seeing.  It just came to my mind as a similar oddity.  It is possible 
that it's that oddity triggering it, but with different results due to 
some other oddity, or if you're on 32-bit, maybe it's the same oddity 
expressed in 32-bit where mine is 64-bit (x86_64 aka amd64).

Two: About how pan's cache works:  Pan saves the actual messages using 
the message-ID as the filename, translating filesystem-invalid characters 
where necessary.  It's thus possible to troubleshoot if you can figure 
out the message-ID (say from the attribution of a reply, or by grepping 
the cache for a file containing the subject, author, group, etc.

If you save the message text, pan uses the same message-id for saving 
that, possibly just copying the cache file to wherever you save the 
message, possibly copying the message as in pan's own memory buffer but 
using the same message-id as a filename.  It could be worthwhile to try 
that with both the original "duplicated" message, and the fake-duplicate, 
when you see the problem, as an initial troubleshooting measure.

Meanwhile, it seems to me the problem must be that for some reason, pan 
isn't updating its message-ID pointer when you change messages, so you 
see the same one, instead of the new one.  There must be some code path 
without that critical update, or perhaps more likely, with a race 
condition between two threads.  (Most of pan is single-threaded, but 
worker threads are hatched in certain cases, generally where there was an 
observed bottleneck.)

Which brings up the question in regard to threading:  How many 
connections do you have running to each of the servers concurrently, and 
how many CPU cores is your machine?  For the programmers out there (I 
speak and understand the lingo and concepts to some degree, but don't 
claim to be a programmer), it should be clear where I'm going with this.  
Multiple threads, multiple cores processing them, very good recipe for 
thread-races if the code isn't 100% concurrent-multi-entrant.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman