[Dovecot] New generic userdb lookup api

[Sascha Wilde]

Timo Sirainen <tss at iki.fi> writes:
>>> 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.

Hmm, that would be after the end of the imap connection (deliver should
be no problem anyway) -- yes this could indeed take some time...

>> 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.

I think I prefer the first version, as in the second proposal replies
From older lookups would become destroyed with every new lookup, which
IMO would not be really evident to the user of the API.

>>>> 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.

Ok, thanks for your input.  :)

I'll put together an a little improved version this afternoon.

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer:   Frank Koormann,  Bernhard Reiter,  Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://dovecot.org/pipermail/dovecot/attachments/20081027/204b9edc/attachment-0001.bin