On November 4, 1999 at 12:34, Nathaniel Irons wrote:
Thanks for your time; I'll keep my eyes open while poking through the
codebase. Mostly, I'd like to know why the failure is so unpredictable.
MHonArc tries to only update pages that are needed. Threading complicates
things since message addition can cause the message to be listed
anywhere in the index. Unlike date where it is either the beginning
or the end.
For brevity, lets assume we are only talking about threads.
For each message added, mhonarc tags the next and previous messages of
the new message as dirty. It tags the index page it would be on as
dirty (which implies that all later index pages are dirty). It also
tags the next X and previous Y messages dirty as based on TSLICE
setting.
This seems to be sufficient for most cases. However, I think the
problem you are having is that a new message addition causes another
message's index entry to be pushed to the next index page (most new
messages will be listed before most existing messages). However, this
message is not within the TSLICE range, therefore, it never gets tagged
as dirty. With non-reverse listings, this "pushing" is much rarer, and
when it does occur, the pushed messages will more-in-likely fall within
TSLICE.
Note, this "pushing" effect ripples down the list of messages at each
index page boundary. Therefore, adding a single message to a reverse
threaded index, would require very old un-related-to-the-message-added
message pages to be updated.
--ewh
P.S. I believe this reverse "push" problem affects any multi-page
index type. Some testing is required. Interesting problem.
