On Fri, 3 May 2002, Gavin Sherry wrote:
> The latter will be the best solution, since, for example, the lsearch
> driver does not seem to be affected by this bug (anecdotally speaking) --
> although a quick look suggests that it uses similar code. *shrug*.
I've now looked into this more deeply. I would expect lsearch to be
affected if it had lots and lots of lines for an alias list - but
typical lsearch files don't usually do this.
I think I can improve matters generally, without having to patch a
number of different places, by being clever in the string_cat()
function. The comment you quoted was:
/* Extend an existing store block. We must *not* use store_release() here
as is done in a similar bit of code in receive.c because we cannot guarantee
that there are no other calls to the store_xx() functions between calls to
string_cat(). */
It doesn't take much additional code for Exim to remember what the last
call to the store_xx() functions was. Therefore, it can know when it is
in a situation where it is safe to release memory. (I'm gradually
learning to call it "memory" - the modern usage - rather than the older
"store" that I grew up with. Also, I think "store" was always a more
left-pond usage.)
I'm going to experiment with this optimisation.
Nevertheless, for some of the lookups, it still makes sense to
pre-allocate a largish block when you know there are going to be a lot
of data values to be concatenated, so I'll probably do that as well.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
