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), and hope you can give me some hints.
So far I see three ways to eliminate this delay:
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.
2) reload_db() forks and re-loads the database, then calls back to the
parent PID (e.g. via a signal), which in turn passes the listening
socket FD and eventually exits after the last thread finished its work.
3) Run two instances in parallel and create some shell script logic to
make a symlink point to either of the sockets. If you want to
re-load, pick the inactive instance, reload, switch symlink,
reload the second instance.
While option 3 works in practice, it is not really nice in my eyes. On
IRC it was suggested that option 1 (that I favor) is not possible:
16:07 < lattera> there's a lot that happens behind-the-scenes when
dealing with engine reloads due to threading
Is that really the case? If so, is it possible to to maybe only thread
out the time-intensive part, and let the other parts run
synchronously?
I would appreciate any ideas or pointers to the source regarding this
issue. Or how else do people deal with this delay?
Thanks in advance,
Julius
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
