2003-11-30T17:00:50 Marc Balmer: > >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.
_Anything_ is disputable. But I've never heard anybody dispute this before. Threads may occasionally be useful, but only when the intimate sharing is urgently desired; using them as a performance optimization when independent processes would deliver the appropriate semantics is only valuable on systems where process context switching is really, really awful, things like VMS and NT. Unix forks and context switches very very fast, and Linux faster still. > Regarding threads you have to understand the topic. Of course. But understanding it doesn't make it preferable to forked processes except where there's an architectural benefit to the sharing. Where there's no such benefit --- and typical server designs are such a case --- threading buys an uninteresting performance benefit in exchange for a loss of architectural protection. > There are fine books available on threading. There may be. If they advocate threading for jobs like clamd, then _I_ would despite tagging them with the epithet "fine". > >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. Threads are marginally faster if each process is doing a trivial amount of work. Jef Poskanzer experimented with a fork-per-request http daemon, mini_httpd, and found that it wasn't dramatically slower than preforked servers. Forking is pretty quick. And preforked servers are a well-regarded design for high-performance servers; Apache and Postfix are my favourite examples. I hope nclamd gets added to the list. With a pre-forked design, you get the protection advantages of separate processes, while amortizing the fork cost out over the servicing of hundreds of requests. > And then there are BSD systems. Make solution that performs well > on all environments. That would be fine. A system that forked or context switched vastly worse than Linux wouldn't be a Unix, it would be Windows. BSD systems run preforked daemons with elan. nclamd's architecture is the way to go. At least one commercial antivirus vendor has switched from a threaded server to a preforked server for the very same reasons nclamd needs to --- threads are fragile. Bugs that take out one service process from a preforked daemon, causing no service outage, take a threaded daemon all the way down; you end up having to run your threaded daemons under respawners because they're so crashy. Hmm. Smells like Windows again. -Bennett
pgp00000.pgp
Description: PGP signature
