Subj : Re: Futexes are wrong! (Are they?) To : comp.programming.threads From : David Schwartz Date : Mon Jun 13 2005 05:39 pm "Jomu" wrote in message news:1118694635.295293.38720@g49g2000cwa.googlegroups.com... >> 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. :) The poll function is standardized. It's supported on just about every UNIX except Darwin. > And so, there goes your: "standard guarantees that", "portability > this"? If you want the highest performance on any given platform, you must use the operation that provides the highest performance. On no platform I know of or have heard of is thread-per-connection the highest performance. Unfortunately, this means that no matter what, if you want top network performance, you must use IOCP on Windows, kqueue on Darwin, epoll on Linux, and so on. >> > 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. I'm talking about using 'poll'. Why do you keep talking about select? > But, now you're talking poll()... It was select() to this moment... > Stop moving for a moment :). I never said "select()" I just used the word select. I am very careful to use quotes when I mean a specific function and none when I mean a concept. This is absolutely *NOT* about the specifics of any particular function. > And this "optimum" you're talking about - is it something known or > something (ouch) arhitecture/implementation dependent? You don't need optimum. You can just arbitrarily pick 1,000 and know it's going to be a lot closer to optimum than one. > Does standard specify AI prerequisites, needed for this decision > making you're implying? You can allow the user to select it. You can hard code it. You can make it auto-tune. It doesn't matter. Any of these solutions is orders of magnitude better than hard-coding it at one. DS .