On Sun, 2007-06-03 at 19:13 +0100, Ross Burton wrote:
> By pool do you mean memory regions which can be split into children, and
> freeing the parent region also frees the children? That isn't in Glib.
That's the idea in dovecot, yes. Actually, no parent region/child region
but just basically li
On Sun, 2007-06-03 at 18:27 +0300, Timo Sirainen wrote:
> ..Or maybe just fix the basic timeout_*() API. Add a new timeout_reset()
> call == timeout_remove() + timeout_add(original values) and then make
> the implementation be fast with hundreds of timeouts. The timeouts are
> currently kept in li
On Sunday June 03, 2007 at 01:48:33 (PM) Dave McGuire wrote:
> On Jun 3, 2007, at 11:29 AM, Ross Burton wrote:
> > I presume porting Dovecot to use the glib main loop abstraction (which
> > is nice and lean, the object system is a separate library) is out
> > of the
> > question?
>
>Please
On Sun, 2007-06-03 at 11:54 -0500, Richard Laager wrote:
> On Sun, 2007-06-03 at 18:48 +0300, Timo Sirainen wrote:
> > I've used GLib before. The biggest problem I see with it is that it
> > doesn't support memory pools. That's why I duplicated most of its useful
> > functionality originally instea
>
> Please don't. One reason Dovecot is so easy to get up and running
> quickly is that it has minimal dependencies. For those of us who
> aren't running Linux on PCs that can become a headache very quickly,
> as the authors of many of the depended-upon libraries often get
> "creative" with nonpor
On Jun 3, 2007, at 3:45 PM, Richard Laager wrote:
That's not to say that simply adding one dependency on glib would
cause a huge problem...but it indicates the adoption of a mindset,
and it's a slippery slope.
The same applies to duplicating code in the interest of avoiding
dependencies.
On Sun, 2007-06-03 at 13:48 -0400, Dave McGuire wrote:
>That's not to say that simply adding one dependency on glib would
> cause a huge problem...but it indicates the adoption of a mindset,
> and it's a slippery slope.
The same applies to duplicating code in the interest of avoiding
depen
On Sun, 2007-06-03 at 11:54 -0500, Richard Laager wrote:
> On Sun, 2007-06-03 at 18:48 +0300, Timo Sirainen wrote:
> > I've used GLib before. The biggest problem I see with it is that it
> > doesn't support memory pools. That's why I duplicated most of its useful
> > functionality originally instea
On Jun 3, 2007, at 11:29 AM, Ross Burton wrote:
I presume porting Dovecot to use the glib main loop abstraction (which
is nice and lean, the object system is a separate library) is out
of the
question?
Please don't. One reason Dovecot is so easy to get up and running
quickly is that it
On Sun, 2007-06-03 at 18:48 +0300, Timo Sirainen wrote:
> I've used GLib before. The biggest problem I see with it is that it
> doesn't support memory pools. That's why I duplicated most of its useful
> functionality originally instead of just using it directly. So I think
> it's much better to fix
On Sun, 2007-06-03 at 16:29 +0100, Ross Burton wrote:
> My poor laptop is running a IMAP server, a HTTP server and a SMTP
> server.
>
> > > This fixes it for imap/pop3-login:
> > > http://hg.dovecot.org/dovecot/rev/0021765627f3
>
> Sweet, although this still wakes up when there are clients connec
On Sun, 2007-06-03 at 18:27 +0300, Timo Sirainen wrote:
> ..Or maybe just fix the basic timeout_*() API. Add a new timeout_reset()
> call == timeout_remove() + timeout_add(original values) and then make
> the implementation be fast with hundreds of timeouts. The timeouts are
> currently kept in lin
On Sun, 2007-06-03 at 18:13 +0300, Timo Sirainen wrote:
> > I did once try to reduce these unnecessary wakeups, but then I thought
> > it's probably not worth the trouble. No-one's going to run an IMAP
> > server in their laptop.. :)
:)
My poor laptop is running a IMAP server, a HTTP server and
On Sun, 2007-06-03 at 18:13 +0300, Timo Sirainen wrote:
> Maybe the optimal solution would be to create a new abstraction layer.
> Most of the timeout handlers are just checking for idle timeouts.
>
> struct idle_timeout *idle_timeout_new(unsigned int secs,
> timeout_callback_t *callback, void *co
On Sun, 2007-06-03 at 18:05 +0300, Timo Sirainen wrote:
> > My laptop runs a local IMAP server so that I'm immune from breaking my
> > mail client, and when playing around with powertop I discovered that
> > Dovecot (in particular imap-login) wakes up every 1000ms and then every
> > 50ms even when
On Sun, 2007-06-03 at 14:06 +0100, Ross Burton wrote:
> Hi,
>
> My laptop runs a local IMAP server so that I'm immune from breaking my
> mail client, and when playing around with powertop I discovered that
> Dovecot (in particular imap-login) wakes up every 1000ms and then every
> 50ms even when n
Hi,
My laptop runs a local IMAP server so that I'm immune from breaking my
mail client, and when playing around with powertop I discovered that
Dovecot (in particular imap-login) wakes up every 1000ms and then every
50ms even when no clients are connected. A bit of stracing shows this:
gettimeof
17 matches
Mail list logo
