Re: [exim] Returning static strings from dlfunc?

Inizio della pagina
Delete this message
Reply to this message
Autore: Janne Snabb
Data:  
To: exim-users
Oggetto: Re: [exim] Returning static strings from dlfunc?
On 05/07/2012 03:27 PM, Phil Pennock wrote:
> On 2012-05-07 at 10:44 +0700, Janne Snabb wrote:
>>
>>     *yield = string_copy(US"foobar");

>
> This is safer. It will make a copy which should be valid for the
> lifetime of the current memory allocation pool, and the caller should
> have made that a longer-lived pool if necessary for its purposes.


Ok. Thank you for your answer. Unfortunately this is where it gets
complicated. I wanted to avoid this complication.

According to the Exim specification[1]:

The dynamic memory that Exim uses when receiving a message is
automatically recycled if another message is received by the same
process

...and also:

Because it is recycled, the normal dynamic memory cannot be used for
holding data that must be preserved over a number of incoming
messages on the same SMTP connection. However, Exim in fact uses two
pools of dynamic memory; the second one is not recycled, and can be
used for this purpose.

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

Should I always manually set "store_pool" to POOL_PERM to make sure that
the allocated memory won't be recycled too early (in case my dlfunc is
called from acl_smtp_connect and the SMTP session delivers several
messages)?

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?

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?

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?

[1]
http://www.exim.org/exim-html-current/doc/html/spec_html/ch42.html#SECTmemhanloc

--
Janne Snabb / EPIPE Communications
snabb@??? - http://epipe.com/