Я не могу найти какую-либо информацию об этом в Google, поэтому я публикую здесь, надеясь, что кто-то может помочь …
Моя проблема с функцией Windows pthread pthread_cond_timedwait()
, По истечении указанного времени функция должна вернуться со значением ETIMEDOUT. Вместо этого в моем коде, где его условная переменная не сигнализируется, он возвращает значение 138 и делает это намного раньше ожидаемого времени ожидания, иногда сразу.
Итак, мои вопросы: что это за ошибка 138? И почему тайм-аут не полностью истек?
Код, который я использую для потока:
int retcode = 0;
timeb tb;
ftime(&tb);
struct timespec timeout;
timeout.tv_sec = tb.time + 8;
timeout.tv_nsec = tb.millitm * 1000 * 1000;
pthread_mutex_lock(&mutex_);
retcode = pthread_cond_timedwait(&cond_, &mutex_, &timeout);
pthread_mutex_unlock(&mutex_);
if (retcode == ETIMEDOUT)
{
addLog("Timed-out. Sending request...", LOG_DEBUG);
}
else // Something happened
{
std::stringstream ss;
ss << "Thread interrupted (Error " << retcode << ")";
addLog(ss.str().c_str(), LOG_DEBUG);
}
Что-то не так с моим вычислением абсолютного тайм-аута?
Только этот поток и вызывающий поток присутствуют. Вызывающий присоединяется к созданному сразу после его создания и правильно ждет, пока он не завершится.
В настоящее время условная переменная cond_
никогда не сигнализируется, но если я попытаюсь это сделать, pthread_cond_timedwait()
возвращает значение 0, как и ожидалось.
Даже если не показано здесь, оба cond_
а также mutex_
правильно инициализированы (если я не делаю этого, я получаю ошибку EINVAL).
Также после кода pthread я не могу найти эту ошибку. Я могу найти только некоторые return errno
это могло бы произвести это, но я не знаю значения 138.
Если это может помочь, я использую Visual Studio 2003 с pthreads win32 v2.9.1.
Спасибо,
RG
Может быть, этот ответ будет полезен для кого-то.
Я столкнулся с той же проблемой. pthread_cond_timedwait возвращает ошибку 138
Я перерыл весь исходный код pthread_win32, но не нашел ничего похожего на код ошибки 138.
Я скачал исходный код pthread, собрал его с Visual Studio 2008 и … все работает хорошо! 🙁
Причиной такого поведения является то, что предварительно скомпилированная dll была построена с MSVC100, но я создаю свое приложение с MSVC90. ETIMEDOUT в MSVC100 — 138, а в MSVC90 — 10060.
Это все! Это Windows, братан!
Других решений пока нет …