Subj : Re: Futexes are wrong! (Are they?) To : comp.programming.threads From : doug Date : Mon Jun 13 2005 09:41 pm "Jomu" wrote in message news:1118683254.093964.9310@z14g2000cwz.googlegroups.com... > > > David Schwartz wrote: >> "Jomu" wrote in message >> news:1118642255.487400.283850@g43g2000cwa.googlegroups.com... >> >> > Was I not clear enough with subject? >> >> The discussion clearly has nothing whatsoever to do with the subject. >> The subject is a legacy from many, many posts ago. Any relationship to >> futexes is long lost. >> > > But has with platform. I did not pretend to be interested in anything > except NPTL. > > ... >> >> Just please, name two advantages of thread-per-client. I've named at >> least six advantages of a thread pool. > > 1. You don't have to make 10,000 bit bitset for select() call on > 10,000 fd's; You're unlikely to get 10,000 threads running either. > > 2. Your kernel does not have to operate on (and nobody claimed it's > been O(1)-ed) 10,000 bit bitset; Yes, but at least that thread will get something done. As others have said, there's a good chance that one of your (hypothetical) 10,000 threads will be treated unfairly, and will never actually get any CPU time to run it's code. There is no mention whatsoever of fairness in the specs. > > 3. Of course you'll handle one real client in more than one thread > (think browser opening 4 connections) so it's no use to pretend there > is less "competition". It's only organized in another fun way :). > .... I'd want to handle multiple clients in one thread (not multiple threads for one client, as you said). If such and such client processing requires some I/O, make it async. Pick the result up later. > > dd > >> >> DS > .