Subj : Re: Futexes are wrong! (Are they?) To : comp.programming.threads From : Jomu Date : Mon Jun 13 2005 02:30 pm David Schwartz wrote: > "Jomu" wrote in message > news:1118683254.093964.9310@z14g2000cwz.googlegroups.com... > > >> 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; > > If you want simplicity, you can use 'poll' with a thread pool. If you > want the highest possible performance, you can use whatever provides the > best performance on your OS. It's so portable... just thinking about it hurts my brain. :) And so, there goes your: "standard guarantees that", "portability this"? > > > 2. Your kernel does not have to operate on (and nobody claimed it's > > been O(1)-ed) 10,000 bit bitset; > > Same answer. > > There is some ideal number of connections to 'poll' on. It's probably > not one and it's probably not 10,000. With a thread pool, you can have your > I/O threads 'poll' on the optimum number of sockets each. 10,000 would be maximum fd in address space - if you have 10 threads, 1000 clients each, you'll still need thousands of bits bitsets - without some serious fd shuffling, you'll need 10 10,000 bit bitsets. But, now you're talking poll()... It was select() to this moment... Stop moving for a moment :). And this "optimum" you're talking about - is it something known or something (ouch) arhitecture/implementation dependent? Does standard specify AI prerequisites, needed for this decision making you're implying? > > Try again. Yes, again. :) > > DS .