Re: [Pan-users] Speed of pan

[Duncan]

On Friday 01 November 2002 12:00, Brian Morrison wrote:
> On Fri, 1 Nov 2002 11:02:55 -0600
>
> Carl Wilhelm Soderstrom <address@hidden> wrote:
> > what about starting the GUI, and walking the cache with another thread
> > running in the background?
>
> That would be by far the best solution, you then have no problem with
> the cache files and the cache storage file being incoherent.
>
> But, does Linux do threads well? I always felt that it seemed not to,
> whereas previously as an OS/2 user I was really spoiled in this regard.

[This thread branched to the devel list, where I wrote a more detailed 
response on some aspects, for those interested.  This one is more detailed in 
regard to threading, however, as the discussion here went in that direction, 
where the one on devel, didn't.]

Newer PANs do exactly that.  There are, however, somewhat complex potential 
race conditions between the threads, when you do it that way, and a "bug" in 
the current series as a result.  (The bug is simply that things get a bit 
confused, if you load a group b4 the other thread has had a chance to load 
the entire cache, with PAN then reporting messages uncached that actually 
are.  This becomes more confusing when you have PAN set to auto-check for new 
messages to a group, upon entry.  However, once one realizes what is going 
on, it is behavior as now designed, not a bug, as such.)

Linux does indeed have threading, using the common fork functionality that 
also allows an app to launch a second app, but with different parameters, and 
PAN indeed has used it for quite some time (see the FAQ answer dealing with 
memory use).  The issue with threading is that historically, Linux threads 
haven't been particularly lightweight, compared to those on other OSs.  (This 
becomes increasingly apparent at enterprise level threading -- thousands of 
threads, handling hunreds of queries a second, for a commercial database app, 
for instance, but can still make some difference at ordinary user level, such 
as with PAN.)  They are almost more like separate processes, than multiple 
threads on the same process, in some ways.  There has, however, been some 
serious recent work in the 2.5 kernel series in this regard, and the 2.6 
stable kernel series should be much improved, here.  Of course, existing apps 
written to be thread-frugal will have to be re-written to take advantage of 
more threads, now that they can, without all the former overhead. 

The weekly kernel section at LWN (Linux Weekly News) discusses new kernel 
developments such as this every week.  That's where most of my knowledge on 
it comes from.  They do a real good job of explaining things for those of us 
that aren't kernel developers, and don't care to get into the extremely 
technical details.   They now have a subscription model that delays release 
of the weekly writeup by one week, publicly, during which time it is only 
available to subscribers, but developments like this in the kernel aren't 
likely to be used for some time, so a week's delay doesn't matter to much, 
except that the discussion threads are a bit stale, by then (although that 
can be and advantage, as well, as you get to see the contributions of people 
you wouldn't have, had you gotten it the week earlier, and not come back to 
see the discussion, later).

-- 
Duncan
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin