Re: [Boost-users] Crash in boost::thread::sleep(xt) (boost 1.42 on Windows 32 bit)

Subject: Re: [Boost-users] Crash in boost::thread::sleep(xt) (boost 1.42 on Windows 32 bit)
From: Arno (arno.schaefer_at_[hidden])
Date: 2012-03-30 04:34:05

Hi Neil,

many thx for your hints, it brought me on the right way.

> In that case you might be in the same situation I was in. Our third-party libs
used Boost.Thread statically linked. It took me quite a while before I realized
this was a possible cause of the problem. I could see a completely messed-up
context when catching the exceptions with the debugger.

Meanwhile I found out, that the third party libs didn't use boost, but heavily
used win-threads, with thread pooling mechanisms. In our huge structure, I also
found some code, what implements a kind of watchdog on a given thread id. There
was looked for a somehow specified timeout and if the timeout became active the
thread was directly terminated with the WINAPI function 'TerminateThread(...)',
so boost thread can not recognize this, and so I have had the situation, that
the thread sometimes crash in the sleep function or leave mutexes in an
inconsistent state.
So by the way, have you an example how is the right way to terminate a boost
thread? I haven't understood the 'interuptable' things in the documentation.

> Sorry for missing this information out previously, I am having issues with
Trac and could not find the thread of discussion with Anthony. I have finally
found the threads of discussion and the changes were merged into Boost 1.47.

So I believe it has nothing to do with the fix, but if you can found this
communication with Anthony (perhaps he read this ;-), I am very interessted in
this disscussion, because we have some more complicated problems in the multi
threaded area, what can at least explained simalar to the ODR violation fix, if
we know at least the circumstances of this fix.

> Can you try Boost 1.47? If this does not work, then we can explore alternative
approaches. 

I have done a test with 1.49, but I can not switch to it completly, because of
other issues with the filesystem library v3 at the moment, but this is another
point. 

best regards
Arno