> > Someone who develops and tells me that 1000 threads for one single > > application is normal... THATS what I am flameing about. > > That always depends on the application. If I have to write an > application that solves a problem that warrants 1000 threads, why the > hell not? And Freenet has a hell of a lot stuff to do. Using threads is > a logical and fast way to solve a certain class of problems and there's > nothing wrong with doing it that way.
Logical? Only for programmers not knowing the gigantic overhead of threads. Fast? Its probrably for most problems not even faster to develop, especially since multithreading always leads to the nastiest bug ever. And for the application its obvious that it gets slower with each thread. There is much wrong with using so many threads. debugging impossible, still nobody can tell me where all those threads come from. Thats a very good security aproach to make it undebuggable. How do you think are IRC Servers written? NO, they dont use a sheer amount of threads. Even though in that case the benefit would be obvious. You know why they dont use many threads? because they couldnt serve thousands or tenths of thousands users simultanously. It would break any reasonable machine. In particular in Freenet I dont know of any bigger Problem which needs using multiple threads besides the different services, (fred, fcp), and one thread per connection. Maybe its too easy to write new Thread in java, maybe posix threads had its value in its complexity. People using them knew how difficult they are. > as you have mentioned quite correctly - threads are > indeed expensive. Unfortunately in most cases it's either "use a thread" > or "write several hundred lines of code and not use a thread." Yes, I really got upset when I read the answer of toad. Maybe I was a bit harsh. But I think this careless programming leads to more problems than saving some hundred lines of code.
