On Thu, 20 Sep 2001, Davide Libenzi wrote: > > On 20-Sep-2001 [EMAIL PROTECTED] wrote: > > Hi David, > > > > I'm really happy with xmail thus far and I just wanted to let you konw > > that. I've been working on how I can improve performance, however, as you > > know there is a sizable CPU load involved with spawning new processes and > > if an external filter is used with xmail, then of that script or program > > has to run for every message that is processed. > > > > An idea I had along this line was that it might be a good idea to provide > > facilities for at least certain types of scripts to run in a "persistent" > > manner - ie - if one writes a filter for xmail with perl, every time a > > message arrives the perl interpreter has to run, interpret the script and > > then exit. > > > > One idea on this is to make it possible to embed the perl interpreter > > within xmail. There's a good amount of data around on doing this type of > > thing such as at: > > > > >http://aspn.activestate.com/ASPN/Reference/Products/ActivePerl/lib/Pod/perlembed.html > > > > (the line above might get wrapped by your mail client) > > > > Seems like this would be a really incredible advantage since perl is > > probably a common way many would write filters for xmail. And, maintaining > > a persistent perl interpreter would make the execution of filters > > incredibly fast. > > > > I don't honestly know how big a deal it would be to do this as I have > > never done it, but I would be interested in what you think about this. > > I send this reply to the mailing list to share it among the ml subscribers. > As a general rule don not write me directly coz this means that i've to repeat the >same > thing N times. > About your question i understand that it could be expensive to spawn a new > process for every message. > I can say that a perl interpreter will never be included inside xmail but this > does not mean that the problem cannot be solved. > In case of virus scanning you've two big costs : > > 1) execution of the perl interpreter > > 2) execution of the av scanner > > The perl cost could be solved in a way like the fastcgi does for web servers. > There's a perl script that costantly run as server and requests are sent through > pipes/sockets. > In this case the program that you run inside the filter will be a very small > binary ( real binary not script ) that nothing does other than communicate with > the server process. > For the av scanner you can do very little if you don't have access to the library >api. > I don't know if McAfee gives out an sdk for the engine library but i know for sure > that you can't find it inside the package that you purchase at the software store. > > > > > - Davide > Dear Davide, Thanks for your reply but it seems to me that if the filter being executed is a binary you still have the same problem of a new process being executed for every message. Regardless of the size and complexity of the binary, there is a substantial cost in launching it. I know some of the web server solutions are using some type of API to then launch a request. For instance, the web server has an API for which a plugin could be written to then send requests in a FastCGI type idea. I'm not sure how simple it would be to implement though for you. Maybe one of the existing available server modules for fastcgi could be used with some modifications, but I think that there would not be too much benefit to using fastcgi if there was no way to interface to it without launching a separate process each time. -Ree
