On Wed, 5 May 2004, Beau E. Cox wrote:
> > There's a better solution that does not involve tweaking the XMail source
> > code. You have one (or more) pre-loaded Perl interpreters running as
> > servers bound on certain TCP ports, and you have a very small binary
> > (cperl, written in C using sockets) that talks a trivial protocol with the
> > Perl interpreters. You "external" command call will change from:
> >
> > "perl /home/davide/myscript.pl"
> >
> > to:
> >
> > "cperl -s localhost -p 17171 /home/davide/myscript.pl"
> >
> > If the script is not already loaded in the interpreter, it will be at
> > client connection time. Do I have to proceed? :-)
>
> Yes, Davide, I understand that approach.
>
> But even with that approach, the new process overhead ('fork') remains,
> which my code completely eliminates.
Man, you cannot BS me with fork() costs ;) Just for example, and your
eyes:
http://www-106.ibm.com/developerworks/linux/library/l-rt7/?Open&t=grl,l=252,p=mgth
The process create speed is the cost of a fork/exec on a PIII 500MHz, and
it's 3ms. And it's compared to the cost of an interpreted Perl script, that
is most likely going to do a non-trivial task in decoding a message, and
maybe running other tools. You want a plugin interface for XMail? You've
got it. The above one, once the trivial protocol is established, can talk
to Perl servers, Python servers, Ruby servers, Tcl/Tk servers, Java
servers, C# server, (put your list of favourite script languages here).
The above solution, does not touch the XMail code, allows plugging any
script server you like, scale better because you can round robin on many
script-servers if you like, and does not force Perl requirements on XMail.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]
