From xemacs-m  Sun Mar 23 22:11:25 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id WAA15295
	for <xemacs-beta@xemacs.org>; Sun, 23 Mar 1997 22:11:23 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQciey28183; Sun, 23 Mar 1997 23:11:23 -0500 (EST)
Date: Sun, 23 Mar 1997 23:11:23 -0500 (EST)
Message-Id: <QQciey28183.199703240411@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: xemacs-beta@xemacs.org
Subject: Re: VM6.21 problem
In-Reply-To: <199703240328.WAA20794@blight.IntraNet.com>
References: <199703231311.IAA17626@blight.IntraNet.com>
	<QQcidi18708.199703231736@crystal.WonderWorks.COM>
	<199703240328.WAA20794@blight.IntraNet.com>
X-Mailer: VM 6.23 under 19.15 XEmacs Lucid (beta103)
X-Face: /cA45WHG7jWq>(O3&Z57Y<"WsX5ddc,4c#w0F*zrV#=M
        0@~@,s;b,aMtR5Sqs"+nU.z^CSFQ9t`z2>W,S,]:[+2^
        Nbf6v4g>!&,7R4Ot4Wg{&tm=WX7P["9%a)_da48-^tGy
        ,qz]Z,Zz\{E.,]'EO+F)@$KtF&V

Jonathan Edwards writes:
 > Kyle Jones writes:
 > > This looks like normal behavior.  Let VM finish what it is trying
 > > to do.  The sloth is due to buffer gap motion, which probably
 > > involves some system paging on such a large folder.
 > 
 > There is something subtle and asynchronous going on here.  I
 > have reduced the problem to one involving very large
 > UNMODIFIED folders. These have large amounts of background
 > activity (multi-second hangs) in vm-flush-itimer. [shouldn't
 > the cache be empty?]. Further, it seems that sometimes vm-quit
 > will treat an unmodified folder as modified and try to write
 > it out to disk, which causes multi-minute hangs.
 > [...]

(chuckle) I was hoping I wouldn't have to explain this stuff, but
no one is going to believe me when I say this is normal behavior
unless I do. :)  So...

Between 6.19 and 6.21, I added a new slot in the summary cache
substruct of the VM message structure.  The summary cache of a
message is stored in a special header so that summary generation
is fast.  Since 6.21 has a longer summary cache, the stored cache
entries in all folders is now one slot shorter than the struct VM
6.21 expects to find.  VM notices this, expands the cache entry
internally and makes a note that it would like the new, longer
cache entry flushed into the folder buffer at some point.

Enter vm-flush-interval, which tells VM how often to look for
modified cache entries and message attribute changes, and flush
them into the folder buffer.  The default timeout value is 90
seconds, so a minute and half after you visit the folder VM
starts looking for cache entries to flush.  Because you visited
a large folder with a lot of the old short cache entries, there
are a lot entries to flush.  VM proceeds to start flushing them
until there's input pending, at which point it stops.  It waits
another 90 seconds and continues where it left off.  Repeat
until all the flushing is done, or you quit the folder.

When you quit the folder, if there are message marked `new' in
the folder VM changes changes the `new' attribute to `unread'.
If the folder was not modified before this action, it is now.  So
now it needs to be saved.  Part of the save process is flushing
any modified cache entries to the buffer so that they are written
to disk.  The flushing process is _not_ interruptible by ordinary
keystrokes this time, though C-g will break out of it.  Because
the folder is large, the flushing takes a while, but it will
eventually complete at which point the folder will be written to
disk.

See?  All normal.  The reason I wanted you to let VM finish what
it was doing is that once it finished, you would not see the
delay again unless I lengthened the cache further.  The only
reason I did it this last time was to cache some information
needed to fix a threading bug.  Before that, the last time I
extended this structure was three years ago.

-- 
A business card from Ecuador is not sharp enough to saw through a
hanging thread from my jeans.  My Sun mousepad, however, is sharp
enough.

