Re: [Dovecot] New generic userdb lookup api

[Timo Sirainen]

The idea behind Dovecot's memory allocations is that you shouldn't have to go through all the trouble of doing lots of memory frees. Because 1) it's easy to cause memory leaks then, 2) it requires more code and makes

it uglier, 3) possibly increases memory fragmentation.


It could use slightly more memory, but especially for these kind of
short living allocations it really doesn't matter.

So with memory pools you just allocate all the memory from the pool and finally simply free the pool. That takes care of all these 1-3) issues.

Than I don't really see the problem with the current code -- I
understand that all the memory it uses (with i_strdup and friends) is
allocated from the default pool, which I assume will be freed
eventually.

Well, "default pool" isn't really a proper memory pool. p_malloc(default_pool) = p_malloc(system_pool) = i_malloc() = calloc(). It will only get freed when the process is killed.

If the goal of an dedicated pool is to free the memory early the code
using the auth-master API will have to allocate and free this pool, I
don't see the advantage here...  But then, on a second thought I _do_
see the advantage of a consistent way to do things like this.  ;-)

I was thinking something like:

pool = pool_alloconly_create("userdb lookup", 512);
auth_master_lookup(auth, pool, &reply);
// do stuff with reply
pool_unref(&pool);

Or I suppose auth_master_init() could allocate the pool internally and call p_clear() at the beginning of each lookup. Hmm.

Btw, on dedicated vs. default resources, I wasn't quite sure if it was a

good idea to use the default ioloop.  Any thoughts on that?

new ioloop or things will probably break.

For deliver it doesn't matter, but for imap you really should create a

Yes, I know (already made this mistake)...  ;-)
The question is, should the ioloop be an extra argument to
auth_master_init?

I don't think there's any benefit in doing that.

PGP.sig
Description: This is a digitally signed message part