On Mon, 21 Jan 2002, Kevin P. Fleming wrote:
> 1) implement a standard local_scan file that includes an embedded perl
> interpreter, then use external perl scripts to do the work
> 2) use Exim's built-in embedded perl interpreter, and extend its use to
> allow a local_scan function to be called (in addition to using "${perl"
> constructs in string expansions)
From within the C function that is local_scan(), you can call the Perl
interpreter yourself, without having to use the ${perl construct. Take a
look at the perl.c module in Exim. It is not very long. (But don't ask
me about it - I was sent it by a Perl expert.)
> - Would Philip be willing to accept patches (tested, of course :-) to add
> this functionality to Exim 4? I'm thinking this would be an additional
> compile-time option, just like embedding perl is now. The local_scan
> function would get passed some perl data structures (using Mail::Internet
> and other existing modules) that contain all the message information.
I'm not sure this is necessary. The whole idea of making local_scan() a
C function was that people could build interfaces from C to Perl or
anything else, without me having to modify the base Exim source.
> - How often does Exim 4 exec() itself, instead of forking?
Same as Exim 3, when it needs to regain privilege. Typically this is
following the reception of a message, in order to start a delivery
process.
> Each time the
> exec() is done, the perl interpreter gets recreated, reinitialized, and more
> importantly, loses any "state" information that was present in the "master"
> interpreter.
Note that Exim processes can be started by an other local process in
order to receive messages. They don't have to be forked off the daemon.
Indeed, you don't even need to run a daemon.
> With a fork(), the interpreter gets "copied", and still has
> that state information. However, if Exim 4 only exec()'s itself at points
> _after_ which the local_scan() function could ever be called, this is a
> non-issue.
Exec will happen only after a message has been successfully received.
But local messages aren't received via the daemon (though you may not
care about local messages) and of course you get a new exec every time
if you use inetd instead of a daemon.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
