2

I can't find any information on this with Google, so I post here hoping that someone can help...

My problem is with the Windows pthread function pthread_cond_timedwait(). When the indicated time is elapsed, the function should return with value ETIMEDOUT. Instead in my code, where its conditional variable is not signaled, it returns the value 138 and does it much earlier than the expected timeout, sometimes immediately.

So my questions are: what is this error 138? And why is the timeout not completely elapsed? The code I use for the thread is:

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);
  }

Is there something wrong with my absolute timeout computation?

Only this thread and the calling thread are present. The calling one joins the created one just after its creation and correctly waits until it finishes. Currently the conditional variable cond_ is never signaled, but if I try to do it, the pthread_cond_timedwait() returns with value 0 as expected. Even if not shown here, both cond_ and mutex_ are correctly initialised (if I dont't do it, I get a EINVAL error).

Also following the pthread code I can't find this error. I can only find some return errno that could produce it, but I don't know the meaning of the 138.

If it can help, I am using Visual Studio 2003 with pthreads win32 v2.9.1.

Thanks,

RG

Rusty Gear
  • 455
  • 1
  • 4
  • 11
  • 1
    You hopefully have the source to the win32 pthread port. Crazy as it sounds, **debug it**. Just step into it, get to the kernel wait op (likely a WaitForMultipleObjects() call, but I'm not familiar with the precise implementation), and determine how they're doing what they're doing, and why they're returning the value you're getting. I suspect it is an improperly setup timeout, but it would be sheer speculation, as I avoid pthread timed functions like the plague. – WhozCraig Apr 19 '13 at 23:12
  • @WhozCraig I was using a pre-built library/DLL, so in order to follow your hint I rebuilt it in Debug mode. With this one, my code magically started working and I didn't receive any unexpected error. No more problems even using a rebuilt Release library... – Rusty Gear Apr 20 '13 at 13:45
  • @WhozCraig Why do you avoid pthread timed functions? What do you do when you need to wait some time and still be able to react to external signals? Different libraries or different strategy? – Rusty Gear Apr 20 '13 at 13:47

1 Answers1

1

Maybe this answer will be helpful for someone.

I encountered with the same issue. pthread_cond_timedwait returns error 138 I rummaged all source code of pthread_win32 but didn't find anything similar to error code 138. I downloaded source code of pthread, built it with Visual studio 2008 and... all work nice! :(

Cause of such behaviour is that precompilled dll was built with MSVC100, but I build my app with MSVC90. ETIMEDOUT in MSVC100 is 138, but in MSVC90 is 10060.

Thats all! It is Windows, bro!

Yuriy
  • 377
  • 1
  • 2
  • 10