[Dbmail-dev] [DBMail 0000070]: Fails to give reponse upon completion of rcpt

2004-09-20 Thread bugtrack
The following bug has been REOPENED. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=070 == Reported By:danweber Assigned To:

[Dbmail-dev] [DBMail 0000087]: Possible memory leak in session and db code for pop3d

2004-09-20 Thread bugtrack
A BUGNOTE has been added to this bug. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=087 == Reported By:ljackson Assigned To:

[Dbmail-dev] refactoring plans for 2.1

2004-09-20 Thread Paul J Stevens
Hi all, As promised I've been busy reworking imapcommands.c lately. Since what I'm doing will be pretty invasive wrt the imap code I want to share with you some of the progress made and what I plan to do... 1) change the signature for all _ic_XXX functions 2) change the way results are

Re: [Dbmail-dev] refactoring plans for 2.1

2004-09-20 Thread Leif Jackson
Along with this I would like to start a discussion on the possiblity for doing away with the fork code and going to a pthread model with a thread pool, I have already starting some proof of concept code on my own, but with the performance on threads in linux 2.6.8 and the performance of threads on

RE: [Dbmail-dev] refactoring plans for 2.1

2004-09-20 Thread Wolfram A. Kraushaar
Would be nice if this gets configurable like with the mpm modules in apache 2, so systems without pthreads are also supported. just my 2 cent Wolfram -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leif Jackson Sent: Montag, 20. September 2004

RE: [Dbmail-dev] refactoring plans for 2.1

2004-09-20 Thread Leif Jackson
If we're using Glib, then let's also use Glib's threading interface. It gives us transparency over a variety of thread implementations and platforms, and provides for graceful failure in case there is no thread implementation at all. The issue is that glib's thead pool won't work for an