Re: Reusing message info instances after remapping

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2006-11-09 at 22:57 +0100, Philip Van Hoof wrote:
> 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.

Note that this commit introduced a big memory leak in the content-info
when downloading new messages from for example an IMAP service.

Fixing this

> 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
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
blog: http://pvanhoof.be/blog