今天是客户要求的最后期限，可突然发现一种操作方式下，程序会很容出现线程大面积卡住。
程序开了数十个线程，每个都会ping一个ip。
于是有人说是线程太多，有人说是发包太多，还有说是usleep会导致卡死。
gdb连接上卡死的程序:
gdb main pid
info threads
发现确实很多程序处于usleep。
网上很多说用select的，同事给了一段用select的，结果最基本的sleep时间都远远不对（估计是什么低级错误）。我也不喜欢select，因为效率低。
后来换了naosleep，
void sleepSelect1(unsigned int us, char* file, int line)
{
struct timespec ts1;
struct timespec ts = {
us / 1000000,
(us % 1000000) * 1000
};
while ((-1 == nanosleep(&ts, ts1)) && (EINTR == errno));
}
结果还是会全面卡住，而且似乎更快，
后来换pthread_cond_timedwait：
void sleepSelect2(unsigned int us, char* file, int line)
{
pthread_mutex_t *mutex = malloc(sizeof(pthread_mutex_t));
pthread_cond_t *cond = malloc(sizeof(pthread_cond_t));
memset(mutex, 0, sizeof(pthread_mutex_t));
memset(cond, 0, sizeof(pthread_cond_t));
struct timespec *deadline=malloc(sizeof(struct timespec));
struct timeval *now=malloc(sizeof(struct timeval));
gettimeofday(now,NULL);
long nanoseconds = (us % 1000000) * 1000;
deadline->tv_sec = now->tv_sec + seconds;
deadline->tv_nsec = now->tv_usec * 1000 + nanoseconds;
if( deadline->tv_nsec >= 1000000000L )
{
deadline->tv_nsec -= 1000000000L;
deadline->tv_sec++;
}
pthread_mutex_lock(mutex);
pthread_cond_timedwait(cond,mutex,deadline);
pthread_mutex_unlock(mutex);
free(deadline);
free(now);
free(mutex);
free(cond);
}
同样会大面积卡住在 pthread_cond_timedwait。而且发现把sleep(50)这样专用 cond_timedwait会直接卡住。
后来我发现sleep最终也是nanosleep实现的，nanosleep要传2个参数，我却没有搜索到第二个参数的意义。这让我想起另外一个函数gettimeofday的第二参数，我都是传的null。。。。
下面这段代码，用上之后：程序没有卡住了：
void sleepSelect1(unsigned int us, char* file, int line)
{
struct timespec ts = {
us / 1000000,
(us % 1000000) * 1000
};
while ((-1 == nanosleep(&ts, NULL)) && (EINTR == errno));
}
#define sleepSelect(us) sleepSelect1(us, __FILE__, __LINE__)
sleepSelect就等同于 usleep