On Sun, 30 Nov 2003 23:00:50 +0100 Marc Balmer <[EMAIL PROTECTED]> wrote:
> James,
>
> > 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.
>
> This is disputable. Regarding threads you have to understand the
> topic.
I agree with James - I think it's not possible to write a really stable
multithreaded deamon that uses a lot of software from other authors.
> There are fine books available on threading.
Heh, they usually forget to mention a watchdog is a must for threaded
daemon.
> > 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's an easy work around but performance is bad if you are spawning
> processes. Threads are faster, but you have to be careful in your
> programming.
And audit/rewrite all the software your program depends on ;-)
> > 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.
>
> And then there are BSD systems. Make solution that performs well on
> all environments. That would be fine.
Well, it should be quite efficient under BSD, too.
Best regards,
Tomasz Kojm
--
oo ..... [EMAIL PROTECTED] www.ClamAV.net
(\/)\......... http://www.clamav.net/gpg/tkojm.gpg
\..........._ 0DCA5A08407D5288279DB43454822DC8985A444B
//\ /\ Mon Dec 1 15:03:03 CET 2003
pgp00000.pgp
Description: PGP signature
