As mentioned above, cleaning up resources is definitely harder in a threaded environment,There _are_ current issues with thread-based clamd (and thread-based software in general, as everything (memory, fd's etc)is shared between threads:IMHO ClamAV already has production quality. At least we use it on some production servers and since the release of 0.65 there was not a single problem with the software. The team really made a big, big effort between 0.60 and 0.65.
I have a lot of experience of both thread and fork based network services applications, and it is my opinion that for a solid stable robust service it is not possible to use threads. The shared leaking issue in particular makes it too problematic.
I have written an alternative "clamd", "clamdscan" and "clam-milter" that use the most excellent ClamAV scanning engine (libclamd), but uses a process based model instead of a threads based model for "clamd".
It is available for download at :-
http://www.kyzo.com/nclamd/
It compiles of Slackware v7.0 and v8.1 and I have had reports of it compiling on a number of version of RedHat without and difficulties.
After a huge number of memory leaking issues in the "mbox.c" code we dropped it in favor if "ripmime", which is not only faster, but also doesn't leak.
"nclamd" has a number of advantages over "clamd", particularly, it is more robust, more reliable and the amount of resource it takes up can be controlled.
We sell a Linux solution into small businesses and now have our new "clamd" installed at 35 sites and it is proving utterly reliable.
I have posted numerous messages on this subject on this mailing list and I often worry that it sounds like I am putting down the excellent efforts of both Thomaz and Nigel. This is not the case. However, as we are installing Linux into sites where there is no on-site technical support and so the box has to be utterly reliable.
Our most reliable system hs been up 467 days since it was last rebooted. We are only a two man business, but we have well over 200 system installed. To only way we cn support that number of Linux boxes is by making them mind blowingly reliable. A group of schools in Finland just throw out all the Microsoft servers (about 17) to install our Linux instead "because it works".
I use it in production environments at a number of clients too. One of it being an (albeit small) ISP. But since I use it with amavisd-new, I can only comment on the clamav core, not the mbox or archive code. Following the posts on the ML, that code is much much better in 0.65, but I doubt it's completely bug free.
> On a busy server it will be problematic to spawn a process > for every mail message.
Yes, and no. This is obviously NOT the way to do it (and *not* the way that "nclamd" does it) , but (on Linux anyway) forking a process is pretty much the same cost as forking a thread, both of which are pretty cheap. It is because fork() is often followed by exec() that it has got a bad reputation - exec() is pretty expensive.
James
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Clamav-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-devel
