Mailing List Archive: [PATCH] Dynamically loaded lookups -- part 1.

[PATCH] Dynamically loaded lookups -- part 1.

dwmw2 at infradead

Feb 28, 2005, 9:20 AM

Post #1 of 6 (2473 views)

First step -- make search_findtype() return a 'struct lookup_info *'
instead of an index into the lookup_list[] array. Patch attached.

Next we'll probably want to get rid of lookup_list[] altogether and use
a tree of available lookup types instead. Then we can actually look at
making them dynamically loadable.

I'm slightly dubious about getting rid of lookup_list[], because that'll
mean we have to build the lookup tree at process startup time _every_
time. I wonder if we should use lookup_list[] _and_ a separate tree of
dynamically-added lookup types? Or maybe we can come up with some hack
so the tree is inside the binary is already built correctly?

Either way, this patch would be required first...

--
dwmw2

Re: [PATCH] Dynamically loaded lookups -- part 1. [ In reply to ]

Nigel.Metheringham at dev

Feb 28, 2005, 9:50 AM

Post #2 of 6 (2430 views)

On Mon, 2005-02-28 at 16:20 +0000, David Woodhouse wrote:
> Either way, this patch would be required first...

Oops - patch made rather smaller by the mailing list settings. Have
reset them to the same as exim-users

Nigel.
--
[ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ]
[. - Comments in this message are my own and not ITO opinion/policy - ]

Re: [PATCH] Dynamically loaded lookups -- part 1. [ In reply to ]

Feb 28, 2005, 10:03 AM

Post #3 of 6 (2424 views)

On Mon, 28 Feb 2005, David Woodhouse wrote:
>
> Next we'll probably want to get rid of lookup_list[] altogether and use
> a tree of available lookup types instead. Then we can actually look at
> making them dynamically loadable.

Why not just make the lookup_list bigger, and insert dynamically-loaded
lookups into it as necessary?

> I'm slightly dubious about getting rid of lookup_list[], because that'll
> mean we have to build the lookup tree at process startup time _every_
> time.

There aren't enough lookups for this to be a significant cost.

Tony.
--
<fanf@exim.org> <dot@dotat.at> http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}

Re: [PATCH] Dynamically loaded lookups -- part 1. [ In reply to ]

dwmw2 at infradead

Feb 28, 2005, 11:23 AM

Post #4 of 6 (2424 views)

On Mon, 2005-02-28 at 17:03 +0000, Tony Finch wrote:
> Why not just make the lookup_list bigger, and insert dynamically-loaded
> lookups into it as necessary?

It's currently searched by binary chop.

Patch at http://david.woodhou.se/exim-4.50-lookuptable-1.patch

--
dwmw2

Re: [PATCH] Dynamically loaded lookups -- part 1. [ In reply to ]

Feb 28, 2005, 11:26 AM

Post #5 of 6 (2430 views)

On Mon, 28 Feb 2005, David Woodhouse wrote:
> On Mon, 2005-02-28 at 17:03 +0000, Tony Finch wrote:
> >
> > Why not just make the lookup_list bigger, and insert dynamically-loaded
> > lookups into it as necessary?
>
> It's currently searched by binary chop.

I know :-) Insertion into a sorted array isn't hard or expensive when the
array is small (as it is in this case).

Tony.
--
f.a.n.finch <dot@dotat.at> http://dotat.at/
NORTH UTSIRE SOUTH UTSIRE: NORTH BECOMING CYCLONIC 4 OR 5, THEN SOUTH OR
SOUTHEAST 5 TO 7 LATER. WINTRY SHOWERS. MODERATE OR GOOD.

Re: [PATCH] Dynamically loaded lookups -- part 1. [ In reply to ]

dwmw2 at infradead

Feb 28, 2005, 11:42 AM

Post #6 of 6 (2423 views)

On Mon, 2005-02-28 at 18:26 +0000, Tony Finch wrote:
> I know :-) Insertion into a sorted array isn't hard or expensive when the
> array is small (as it is in this case).

True. It gives us a limit on the number of additions, but I suppose
that's reasonable enough.

I really don't care either way -- I'll do whatever's considered best.

I'm more interested in getting sqlite support included so I can remove
the ${run {sh -c "echo ... >> lsearchedfile"}}} from the greylisting
stuff I'm playing with at http://david.woodhou.se/acl-greylist but I
couldn't bring myself to add another lookup type (and runtime
dependency) without the dynamic loading.

--
dwmw2