Hi Paul, I'd like to test this (less MEMPOOL) on production sinse I have to make an upgrade to my installation that already should had been done about in 2010.
> -----Original Message----- > From: dbmail-dev-boun...@dbmail.org [mailto:dbmail-dev- > boun...@dbmail.org] On Behalf Of Paul J Stevens > Sent: quarta-feira, 29 de Maio de 2013 22:21 > To: DBMAIL Developers Mailinglist > Subject: [Dbmail-dev] 3.1.0 pre-announcement Re: [SCM]Paul's DBMail > tree branch, master, updated. ea836fd3c418cdc6b87123aea3f2a2fda5f60de7 > > > Hi all, > > Below change is actually quite a milestone for me. It appears to iron > out the last remaining problems from quite an invasive audit, cleanup > and refactoring of as much of imapd's memory usage as I could stomach > at this point. > > This means the current master is now officially ready again for real- > world testing. If it holds up over the next week or so I plan to > release it as 3.1.0, indicating the amount of changes going in. > > Test results regarding the memory footprint are rather inconclusive at > this point, so I can't be sure the memory footprint has really changed. > > One thing of import for some perhaps: > > I did add a really experimental memory-pool implementation to the code. > It's disabled by default. Running with DM_POOL=yes in the environment > will activate it. But be careful. > > It's an third-party implementation that looked really nice and behaved > well in the initial tests. Now that I've started using it in my dog- > food production setup, I'm not so sure any more. So be mindful if you > plan to play with it. Ymmv, and I'd be interested to hear how it works > in different scenarios. > > I thought it would be good to be able to give each connected client > it's own memory arena. But with hindsight it doesn't seem like a good > idea any more; particularly for daemons handling many concurrent and > long-running clients, like imapd. It just doesn't scale very well as it > now stands. > > Still, being able to use separate memory arenas still seems like a neat > idea. I will give it more consideration, and leave it at that for now. > > ## > > > On 05/28/2013 05:14 PM, Paul J Stevens wrote: > > This is an automated email from the git hooks/post-receive script. It > > was generated because a ref change was pushed to the repository > > containing the project "Paul's DBMail tree". > > > > The branch, master has been updated > > via ea836fd3c418cdc6b87123aea3f2a2fda5f60de7 (commit) > > from d9c49cef37dafad0d896795c057bfb3de751b0b2 (commit) > > > > Those revisions listed above that are new to this repository have not > > appeared on any other notification email; so we list those revisions > > in full, below. > > > > - Log > > ----------------------------------------------------------------- > > commit ea836fd3c418cdc6b87123aea3f2a2fda5f60de7 > > Author: Paul J Stevens <p...@nfg.nl> > > Date: Tue May 28 17:14:30 2013 +0200 > > > > IMAP: fix socket write regression > > > > --------------------------------------------------------------------- > - > > - > > > > Summary of changes: > > src/clientbase.c | 6 ++++-- > > src/imap4.c | 3 ++- > > 2 files changed, 6 insertions(+), 3 deletions(-) > > > > > > hooks/post-receive > > -- > > Paul's DBMail tree > > _______________________________________________ > > Dbmail-dev mailing list > > Dbmail-dev@dbmail.org > > http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev > > > > > -- > ________________________________________________________________ > Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin > > * Premium Hosting Services and Web Application Consultancy * > > www.nfg.nl/i...@nfg.nl/+31.85.877.99.97 > ________________________________________________________________ > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
