[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.
>>
>> 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.
>> It could use slightly more memory, but especially for these kind of
>> short living allocations it really doesn't matter.
>
> 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?
>>
>> For deliver it doesn't matter, but for imap you really should  
>> create a
>> new ioloop or things will probably break.
>
> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20081027/8d6734d1/attachment.bin