> (FILE* from fd and vice versa), which are not done properly [patches for
> that sent to Tomasz, but not yet checked in].
They have been included a week ago ;) or CVS on SF still doesn't work
correctly.
> I'd like to redo libclamav to work on memory buffers (using mmap() where
> possible). At least on the platforms I worked on, Linux and Solaris,
> this is a very fast alternative to unbuffered stdio.
This is generally a good idea, but I'm not sure all the archive libraries
in libclamav will support it. The current model is very transparent and
the changes shouldn't brake it.
> 2. Switch from PThreads to fork()/exec() [I can already hear you! :-)].
> It is no news that the current code leaks memory and is missing cleanup
> handlers at thread exit. With the current code layout, I'd say it would
> be easier to switch to fork than do the cleanup stuff properly.
It will be better to add the "UseProcesses" option to clamd instead of
removing the thread code. If you disable ScanMail and ScanArchive (which
is a good idea when using something like amavisd-new) clamd is really fast,
expecially on SMP.
> 3. Add some more archive handlers. At least tar, LHA and ARC. I know it
> may sound a bit foolish given (my own) discussion about recoding
I'm working on tar support, however there are many standards :( and no
GPL library (I've seen a BSD one, but we can't include it).
Best regards,
Tomasz Kojm
--
oo ..... [EMAIL PROTECTED]
(\/)\......... http://www.konarski.edu.pl/~zolw
\..........._ I nie zapomnij kliknac w brzuszek...
//\ /\\ <- C. Amboinensis www.pajacyk.pl
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Clamav-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/clamav-devel
