Hi,
I use clamd for filtering incoming email. When you issue the "reload"
command, then the accept() loop is paused while the new engine is
re-read and re-compiled. This might take some seconds, during which
the mails queue up. I'd like to get rid of this delay (if necessary by
patching clamd), an
Hi,
> 1) Start reload_db() in a background thread, resume scanning, and call
>back once the new engine is in place; then exchange the pointers
>from old to new engine and free the old one.
FWIW, I have implemented this option, and it seems to work just fine.
Patch is pasted below.
Do you
> > 1) Start reload_db() in a background thread, resume scanning, and call
> >back once the new engine is in place; then exchange the pointers
> >from old to new engine and free the old one.
>
> FWIW, I have implemented this option, and it seems to work just fine.
> Patch is pasted below.
Hi, Mark!
* Mark Pizzolato - ClamAV-devel
[2014-04-07 21:17]:
> I haven't looked closely, but how is the fact that each thread
> (which may currently be scanning a different file and may finish at
> some arbitrary time in the future) has a reference to the current
> engine object handled?
It ap
Hi Julius,
On Monday, April 07, 2014 at 1:50 PM, Julius Plenz wrote:
> * Mark Pizzolato - ClamAV-devel de...@subscriptions.pizzolato.net> [2014-04-07 21:17]:
> > I haven't looked closely, but how is the fact that each thread (which
> > may currently be scanning a different file and may finish at
Hi, Mark!
* Mark Pizzolato - ClamAV-devel
[2014-04-08 00:02]:
> > It appears that for every connection that is acceptey by clamd,
> > the current "engine" value is passed in the "conn" struct. The
> > engine struct has a ref count, and a process "grabs" the engine by
> > calling cl_engine_addref
