[thread] ~condition_variable_any verifications
hi, one of my project uses exit() to terminate the program. this is sometimes called while some threads are waiting on a global condition_variable_any. when calling exit(), this global variable is destroyed while other threads are still waiting on it, which causes BOOST_VERIFY to fire an assertion failure !pthread_cond_destroy(&cond). this scares the hell out of my users. i know that these verifications can be really useful in many case, but in my use case, it makes exit() rather unusable, and i'd have to redesign some of the internal logic to avoid this assertion failure. thoughts? thnx, tim
Le 22/02/13 17:17, Tim Blechmann a écrit :
hi,
one of my project uses exit() to terminate the program. this is sometimes called while some threads are waiting on a global condition_variable_any.
when calling exit(), this global variable is destroyed while other threads are still waiting on it, which causes BOOST_VERIFY to fire an assertion failure !pthread_cond_destroy(&cond). this scares the hell out of my users.
i know that these verifications can be really useful in many case, but in my use case, it makes exit() rather unusable, and i'd have to redesign some of the internal logic to avoid this assertion failure.
thoughts?
Which alternative behavior would you expect? Best, Vicente
Le 22/02/13 18:41, Vicente J. Botet Escriba a écrit :
Le 22/02/13 17:17, Tim Blechmann a écrit :
hi,
one of my project uses exit() to terminate the program. this is sometimes called while some threads are waiting on a global condition_variable_any.
when calling exit(), this global variable is destroyed while other threads are still waiting on it, which causes BOOST_VERIFY to fire an assertion failure !pthread_cond_destroy(&cond). this scares the hell out of my users.
i know that these verifications can be really useful in many case, but in my use case, it makes exit() rather unusable, and i'd have to redesign some of the internal logic to avoid this assertion failure.
thoughts?
Which alternative behavior would you expect? I don't know what the standard says about this, but I suspect that you should add a exit handle to join all your threads.
Best, Vicente
i know that these verifications can be really useful in many case, but in my use case, it makes exit() rather unusable, and i'd have to redesign some of the internal logic to avoid this assertion failure.
thoughts?
Which alternative behavior would you expect? I don't know what the standard says about this, but I suspect that you should add a exit handle to join all your threads.
checking my last draft of the standard, there seems to be a better workaround: exit() calls destructors, _Exit() and quick_exit() don't ... unfortunately the later are just c++11 :/ cheers, tim
On Sat, Feb 23, 2013 at 1:04 PM, Tim Blechmann <tim@klingt.org> wrote:
i know that these verifications can be really useful in many case, but in my use case, it makes exit() rather unusable, and i'd have to redesign some of the internal logic to avoid this assertion failure.
thoughts?
Which alternative behavior would you expect? I don't know what the standard says about this, but I suspect that you should add a exit handle to join all your threads.
checking my last draft of the standard, there seems to be a better workaround: exit() calls destructors, _Exit() and quick_exit() don't ... unfortunately the later are just c++11 :/
_Exit is also C99 and POSIX, so it might be supported outside of C++11 mode in many platforms. HTH, -- gpd
participants (4)
-
Giovanni Piero Deretta -
Peter Dimov -
Tim Blechmann -
Vicente J. Botet Escriba