On Mon, May 09, 2005 at 10:30:04AM -0400, Paul Davis wrote: > pthread condition variables look cheap until you get "under the hood" > to see how they are implemented. in linuxthreads, they used kill(2), > which is massively slower than using poll/select.
The ITC_ctrl thing I use was originally developed under Solaris, about 8 years ago. Solaris pthreads & friends were comparable to what NPTL offers now, even then. > i agree that with the advent of futexes, poll is no longer ideal, > however ... and the Posix primitives are the winners now. > unix in general continues to suffer from the lack of a generalized > "block until <something> happens" call, where <something> can be a > change in the state of a file descriptor, a POSIX signal (including > SIGALRM/setitimer timers), a fixed interval of time, a semaphore, a > sysv msgqueue, or any other model of "block-waiting" event. Depends. On the best systems, everything - even poll/select - is build on top of primitives like semaphores and condition variables. I can only hope Linux will evoluate in that direction too. > as a result, if you need to wait for 2 or more kinds of conditions > (e.g. file i/o readiness changes *and* a request from another thread), > then you have to pick one API and squeeze at least one of the > conditions into it (as libclthreads does). this situation is > despicable and ugly, but i suspect it will never be fixed. Since I tend to abstract files / sockets / everything that uses fd into C++ classes, I just give the class its own thread to wait on the fd. That invisible (to the class user) 'helper' thread will do most of the work, and then trigger one of the 32 inputs of the object owner's ITC_ctrl, which is where the waiting on multiple events is done. No poll() is ever required. -- FA
