Nail on head. Pthreads is an extremely difficult API to use, owing first to a poor choice of primitives, the consequences of which are that none of the implemen

Nail on head. Pthreads is an extremely difficult API to use, owing first to a poor choice of primitives, the consequences of which are that none of the implementations are particularly good and their interactions with the rest of the machine/model are ill-defined. For example: You know how hard it is to close() in a multithreaded program? [1] And that’s just one system call— one almost everyone thinks they understand. What hope is there for all the other pthreads-code? For cond/etc: One trick I use is handle passing via an epoll[2]. This works much more reliably than the pthreads API, and whilst it’s slower in a microbenchmark that spins the pthread_cond/mutex/etc apis, real programs don’t do that (or don’t need to), and so it is usually a clear net-win. [1]: http://geocar.sdf1.org/close.html http://geocar.sdf1.org/close.html [2]: http://geocar.sdf1.org/fast-servers.html http://geocar.sdf1.org/fast-servers.html