I've actually done this for Windows (somewhat amusing considering the tagline).
I'm still working on it but I already have a Windows service that embeds the Perl interpreter and handles all of the spamd socket communications. I have plans to port this to Linux once I have the Windows version singing. ie: I have written the code in C++ with some degree of portability in mind. I haven't quite got a comparable performance test environment for it yet (ie: spamd vs my code on Windows or on Linux) but it's looking to be at least twice as fast per message with no discernable memory leaks. This is only a part-time project for me so it's taking a while to round it out. It'll probably be another month or so before I have a Linux port running (currently putting in some queue management stuff in case of excessive load). If you're game, you could alpha test for me? Phil. -----Original Message----- From: Theo Van Dinter [mailto:[EMAIL PROTECTED] Sent: Saturday, 21 February 2004 3:08 PM To: Gary Funck Cc: Spamassassin Devel List Subject: Re: spamd optimization idea On Fri, Feb 20, 2004 at 07:59:44PM -0800, Gary Funck wrote: > Isn't there a kind of belt-and-suspenders justification for restarting > each sub-process (via fork) - that memory leaks may develop, and by > restarting, their effect is reduced. Yeah, but restarting for every message causes a lot of overhead which doesn't need to occur. Allowing the children to exit/restart is pretty simple. We do it in mass-check (--restart), and it's the same type of thing the Apache httpd does. (wondering if we can use some of that code actually... perhaps a C connection manager and perl compute children or something.) -- Randomly Generated Tagline: "I wouldnt trust NT to feed my cat." - Unknown poster on Slashdot
