Re: Reusing message info instances after remapping

[Philip Van Hoof <spam pvanhoof be>]

I'm committing this. If it really doesn't work, I'll roll it back. But
my first tests tell me it's working as expected.

On Thu, 2006-11-09 at 17:13 +0100, Philip Van Hoof wrote:
> Use this one (enables the expunging when removing items)
> 
> On Thu, 2006-11-09 at 16:24 +0100, Philip Van Hoof wrote:
> > 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.
> > 
> > 
> > 
> _______________________________________________
> tinymail-devel-list mailing list
> tinymail-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/tinymail-devel-list
-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be