Couldn't you write a program to pass the message path to a memory resident antivirus? I know Grisoft AVG has an easy to use COM interface. That would eliminate a process load there.
That same program to call the AV COM could have SPAMC code integrated into it... resulting in just one process truly being called per email. I think that is the closest you could get. ------------------------------------------------------------ Jason J Ellingson Technical Consultant 615.301.1682 : nashville 612.605.1132 : minneapolis www.ellingson.com [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shiloh Jennings Sent: Friday, November 05, 2004 10:55 AM To: [EMAIL PROTECTED] Subject: [xmail] Re: [****SPAM****] RE: Re: Spam Filters I admit some performance is currently lost on Cygwin. However, this is = not really what concerns me performance wise. The biggest performance = problem I see is the number of processes getting launched per email, not the use = of Cygwin vs native Win32 compile. As I mentioned, there is a SpamC that = you can build from source included with SA3 that is a native build and not a Cygwin build. But the performance difference between launching a native Win32 version of SpamC and launching a Cygwin version of SpamC is = nothing compared to the performance hit we see from launching so many processes = per hit to begin with. Here are the five processes that we launch for each email: 1) perl.exe 2) cmd.exe 3) spamc.exe 4) cmd.exe 5) clamscan.exe As we all know, launching processes on Windows hurts performance. We = need to be spawning threads instead of new processes. On Linux, launching another process is not nearly as much of a performance cost. The = existing filter design would be fine under Linux, even though it suffers under Windows. What I would love to see on the XMail build for Windows is an option to use dll files instead of launching processes for the filters. = If that were the case, I would write a dll that handled connecting to clamd = & spamd over tcp, and my dll would replace all of the code that is = currently in my perl script for handling parsing and logic regarding the replies = from clam & sa. Then we could see real performance gain under Windows. I am = not all that worried about the performance lost to Cygwin, because it is a fraction of the performance we are loosing to launching additional processes. As soon as we can hook a dll file into XMail for filters, = then I will get excited and write all of the stuff in VC++ as a dll. The existing design we use works. I am not complaining. But I would = love to be able to write all of it as one dll file that ran in process. Then = the only process other than XMail that would need to be running would be clamd.exe. We would not need the performance expense of launching five = new processes per email. Adding the option of dll filters would be enough = of an improvement to get the Windows version of XMail on par with the Linux version of XMail. - 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]
