Re: [boost] [thread] Can boost::this_thread::sleep_for() totally stop the thread?

Subject: Re: [boost] [thread] Can boost::this_thread::sleep_for() totally stop the thread?
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2013-08-03 06:13:19

On Sat, Aug 3, 2013 at 8:42 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> there were an issue fixed on 1.54 https://svn.boost.org/trac/**
> boost/ticket/8136 <https://svn.boost.org/trac/boost/ticket/8136>.
>
> Please, could you tell me if this fix is related?
>

It might be related to this fix mixed with another fix from another
dependency.
I use Ogre3D with TBB, where Ogre3D will look for TBB using a CMake script.
There was a bug I reported[1] recently to the Ogre3D team because in
specific conditions (TBB from sources+32bit)
where the CMake script was adding add_definitions(-D_WIN32_WINNT=0x0501)
which hid some windows functions use by Ogre code.
I fixed it by adding a condition so that it does it only with MinGW (I'm
using exclusively Visual Studio 2012 U3 right now).

Now, I don't know if it's related, but this change looks like it might have
an impact on the fix you're talking about.

As I was saying, I have a friend who can reproduce the bug systematically
(windows Vista, core 2 duo)
so maybe finding a computer with these characteristics might make the issue
find it easily.
When I reimplemented the loop using condition variables - which was
actually better because now
the thread wait as long as the time necessary to spawn the next task and is
woken up when a new task
is pushed in the task priority queue - solves the problem for my friend, so
there might be a strong
difference in waiting code there that might be related?

I'll try to make a repro-case with my friend tomorrow if it helps.

[1] http://www.ogre3d.org/forums/viewtopic.php?f=4&t=78443

Joel Lamotte