Re: Reusing message info instances after remapping

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2006-11-09 at 15:42 +0100, Philip Van Hoof wrote:
> This one seems to work.
> 
> Can people please test this (a LOT)?

I'm still too unsure about the patch to already commit it (this doesn't
happen a lot) :-)

It needs testing, again testing and more testing. Once it works, it will
solve a lot limitations and problems that the mmap technique introduced
(mostly the fact that any change to a single such header means having to
reload all other headers. Which is a consequence of the fact that an
mmap always means mapping the entire file -- in our case it means this,
you can indeed map only parts of the file. But it's not practical to map
regions as large as one header instance --).

I'm still thinking about removing the messages_uid hashtable. Right now
I have to duplicate the key (this is the uid) because remapping means
also remapping the memory where the uid points to. That same memory is
used as key in the hashtable. So also the hashtable (its keys) become
invalid after unmapping and remapping the file.

I solved this by duplicating the uid ans feed the hashtable that
duplicate as key. This is why I said that this is going to consume a
little bit more memory (a few bytes per header, added with heap-admin
cost, multiplied by the amount of headers being used).

The hashtable is actually only really needed for the
camel_folder_summary_uid function. It can be implemented without this
hashtable too, of course (a little search in s->messages).

Thinking, abusing my brains, etc etc :). I can use opinions of the
clever guys who sit here and read ;)... on this one.



-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
blog: http://pvanhoof.be/blog