Author: Phil Pennock Date: To: Janne Snabb CC: exim-users Subject: Re: [exim] Returning static strings from dlfunc?
On 2012-05-07 at 17:22 +0700, Janne Snabb wrote: > However if my dlfunc is called from acl_smtp_connect the current default
> "store_pool" is set to POOL_MAIN and likewise if it is called from
What are you doing with the result?
If you're setting an $acl_c_* variable, then the pool will be set to
What variable are you seeing be referred to, from another ACL, in a
different generation of the POOL_MAIN contents?
If your library needs to persist internal state across calls, you should
stash the value of store_pool away, set it to POOL_PERM, then reset
store_pool back to the stashed values.
It's possible that the default pool should change for some ACLs, but I
don't have enough context to know what problem you're encountering.
> If I always set store_pool to POOL_PERM will my dlfunc cause memory
> leaks, or is POOL_PERM memory also recycled but only at the end of the
> complete SMTP transaction?
POOL_PERM lasts for the lifetime of the process, but Exim is a forking
server, so each connection is handled in one process, and deliveries get
fork/exec'd. There's a lot of process splitting going on, so if you
care about the lifetime of memory beyond a narrow scope, you need to
handle that carefully.
> Or is this a bug in Exim? Should Exim take care of setting "store_pool"
> to POOL_PERM when running a dlfunc in the connect ACL?
Possibly, if I can see what variable the result is being stored away in
and why it's being referred to later, after the lifetime of the pool
generation it's in.
> Or should my dlfunc do some magic on its own to determine what
> "store_pool" it should use, depending on which ACL is calling it?
Almost certainly not; but it's possible that you should be temporarily
setting the pool to POOL_PERM for your particular use-case, always.
This message was posted to the following mailing lists: