Boost C++ Libraries: Ticket #2100: thread fails to compile with -fno-exceptions

attachment set

anonymous — Thu, 10 Jul 2008 04:41:08 GMT

attachment → boost_thread_no_exceptions.diff

milestone changed

Fri, 05 Jun 2009 15:20:24 GMT

milestone Boost 1.36.0 → Boost 1.40.0

I had a look at your patch, most of it looks fine, but you add std::exception as a base class of boost::thread_interrupted. That is a very bad idea, boost::thread_interrupted should not derive from any other type, so that normal exception-handling code will not interfere with interruption handling.

Consider

while (true)
{
  try
  {
    lock_guard<mutex> lock(m_mutex);
    processQueue(m_queue);
  }
  catch (std::exception& e)
  {
     std::cerr << "Error processing queue: " << e.what() << '\n';
  }
}

Currently this loop can be stopped by interrupting the thread, with your change it cannot.

Fri, 05 Jun 2009 15:27:16 GMT

oops, I meant to add a wait on a condition_variable so there's an interruption point...

while (true)
{
  try
  {
    unique_lock<mutex> lock(m_mutex);
    while (m_queue.empty())
      m_cond.wait(lock);
    processQueue(m_queue);
  }
  catch (std::exception& e)
  {
     std::cerr << "Error processing queue: " << e.what() << '\n';
  }
}

viboes — Sun, 22 Nov 2009 19:15:35 GMT

I think that Boost.Thread has not been designed to work without exception. What would be the behavior of the application if we remove just any throw statement? In order to achieve the reporter goal, we should need to add functions returning a return code. IMO this is out of the scope currently. Thus I propose to close the ticket.

Sun, 22 Nov 2009 19:38:15 GMT

Did you look at the patch? Noone suggested changing the interface to use return codes. Are you familiar with boost::throw_exception? It allows the user to decide what should happen. One common option is to abort() instead of throwing.

Sun, 22 Nov 2009 19:41:01 GMT

P.S. I don't object to closing the ticket, but I do object to closing it if it hasn't been properly reviewed and the OP's patch considered. Apologies if I misunderstood, but viboes' comment implied the patch hadn't been looked at

viboes — Mon, 23 Nov 2009 14:18:41 GMT

Replying to Jonathan Wakely <jwakely.boost@…>:

Did you look at the patch? Noone suggested changing the interface to use return codes. Are you familiar with boost::throw_exception? It allows the user to decide what should happen. One common option is to abort() instead of throwing.

I inspected the patch before posting and I know also boost::throw_exception. Do you mean that the application building with -fno-exceptions will be happy to abort instead of throwing an exception?

anonymous — Mon, 23 Nov 2009 14:35:14 GMT

Replying to viboes:

I inspected the patch before posting and I know also boost::throw_exception. Do you mean that the application building with -fno-exceptions will be happy to abort instead of throwing an exception?

Yes. In GCC's standard library using -fno-exceptions will turn any throw into an abort(), see http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html#intro.using.exception.no

So if a user is using GCC and compiling with -fno-exceptions then they *already* expect exceptions to cause the program to abort. The OP's patch does not suggest changing the API to use return codes, it just allows the user to decide what should happen when exceptions are disabled. Which is supported in other parts of Boost and seems like a reasonable request to me.

owner, status changed

anonymous — Tue, 24 Nov 2009 22:28:23 GMT

owner changed from Anthony Williams to anonymous
status new → assigned

I've committed a change to trunk that uses boost::throw_exception in most cases. The only cases I haven't touched are where thread_interrupted is thrown at a cancellation point. Interruption relies on exceptions to work properly, and as Jonathan points out, thread_interruption should not be derived from std::exception (and so won't work with boost::throw_exception).

I'm inclined to think that interruption should not be available with exceptions disabled, in which case this code can be masked with a #ifdef.h

nick@… — Fri, 26 Feb 2010 18:30:37 GMT

I found not only do threads fail to compile with -fno-exceptions but also other utilities. The one I found was /boost/numeric/interval/checking.hpp in the operator() functions of the exception_create_empty and exception_invalid_number structs.

nstewart@… — Fri, 02 Apr 2010 21:13:03 GMT

It seems that 1.42.0 doesn't have this change. I would much rather be using boost for mutex, etc than other pthread/win32 wrappers. But requiring exception support is a deal breaker.

cc set

nigels@… — Fri, 02 Apr 2010 21:13:40 GMT

cc nigels@… added

attachment set

nigels@… — Sat, 03 Apr 2010 18:38:08 GMT

attachment → boost_thread_pthread_thread_data_BOOST_NO_EXCEPTIONS.diff

pthread/thread_data.hpp patch for BOOST_NO_EXCEPTIONS

milestone changed

nigels@… — Sat, 03 Apr 2010 18:53:11 GMT

milestone Boost 1.40.0 → Boost 1.43.0

Attached a small patch so that pthread/thread_data.hpp can compile with BOOST_NO_EXCEPTIONS defined for OSX Leopard (gcc 4.0.1). Interruption just doesn't seem relevant without exception handling support enabled. But that shouldn't hinder the use of other threading facilities.

There is one other minor change I'd recommend for boost::thread and BOOST_NO_EXCEPTIONS harmony: boost/thread.hpp includes boost/thread/future.hpp which seems to require exception handling to be useful. I'll also attach a diff here for simply skipping that include if BOOST_NO_EXCEPTIONS is defined.

attachment set

nigels@… — Sat, 03 Apr 2010 18:58:18 GMT

attachment → boost_thread_hpp_BOOST_NO_EXCEPTIONS.diff

omit boost::thread::future from <boost/thread.hpp> if BOOST_NO_THREADS is defined

type changed

nigels@… — Sat, 03 Apr 2010 19:31:06 GMT

type Bugs → Patches

attachment set

nigels@… — Mon, 05 Apr 2010 17:32:39 GMT

attachment → boost_thread_lib_src.diff

libs/pthread/src/thread.cpp patch for BOOST_NO_EXCEPTIONS

nigels@… — Mon, 05 Apr 2010 17:34:39 GMT

One more patch for compiling the boost library in BOOST_NO_EXCEPTIONS mode. This is to ignore a try .. catch block and disable thread_interrupted throw.

attachment set

nstewart@… — Fri, 07 May 2010 19:42:49 GMT

attachment → boost_thread_hpp_BOOST_NO_EXCEPTIONS_20100507.diff

Updated patch for boost/thread/... for pthread, win32 and future handling of BOOST_NO_EXCEPTIONS

attachment set

nstewart@… — Fri, 07 May 2010 19:46:48 GMT

attachment → boost_thread_lib_src_20100507.diff

Updated patch for boost/thread/... for pthread andwin32 handling of BOOST_NO_EXCEPTIONS, potential redefinition of WIN32_LEAN_AND_MEAN

milestone changed

nstewart@… — Fri, 07 May 2010 19:48:21 GMT

milestone Boost 1.43.0 → Boost 1.44.0

status changed; resolution set

Anthony Williams — Fri, 21 May 2010 17:12:34 GMT

status assigned → closed
resolution → fixed

nstewart@… — Fri, 21 May 2010 17:51:03 GMT

Awesome to see this finally closed. Thanks!

anonymous — Fri, 04 Mar 2011 18:03:22 GMT

Replying to nstewart@…:

Awesome to see this finally closed. Thanks!

It looks like as of 1.46.0 (and svn on 3/4/2011) thread still fails to compile with -fno-exceptions. This patch does not look to have been entirely merged. For example, boost/thread/pthread/thread_data.hpp does not contain the "#ifndef BOOST_NO_EXCEPTIONS" guard around "throw thread_interrupted();".

attachment set

nstewart@… — Sun, 06 Mar 2011 20:37:24 GMT

attachment → boost_thread_BOOST_NO_EXCEPTIONS_20110306.diff

Updated boost thread patch w.r.t trunk revision 69610

anonymous — Sun, 06 Mar 2011 20:39:50 GMT

Indeed, looking at boost/trunk, portions of the previous patch seem to be missing. Attached as ..._20110306.diff - ought to apply cleanly to svn.

Nigel

status, milestone changed; resolution deleted

nstewart@… — Sun, 06 Mar 2011 20:41:31 GMT

status closed → reopened
resolution fixed
milestone Boost 1.44.0 → Boost 1.47.0

Reopened with suggested milestone of 1.47.0

anonymous — Thu, 14 Jul 2011 18:19:46 GMT

Since this missed 1.47.0 any chance it can make it into 1.48.0?

owner, status changed

Marshall Clow — Thu, 14 Jul 2011 18:31:38 GMT

owner changed from anonymous to Anthony Williams
status reopened → new

owner, status, milestone changed

viboes — Sat, 03 Dec 2011 11:19:12 GMT

owner changed from Anthony Williams to viboes
status new → assigned
milestone Boost 1.47.0 → To Be Determined

type changed

viboes — Tue, 06 Dec 2011 23:09:11 GMT

type Patches → Feature Requests

This patch will need some documentation and tests to be complete. Moved to feature request until the missing pieces are available.

milestone changed

viboes — Sun, 08 Jul 2012 16:18:02 GMT

milestone To Be Determined → Boost 1.51.0

Committed in trunk revision 79347.

nigels@… — Sun, 08 Jul 2012 18:56:42 GMT

For the most part, this all looks good in svn main trunk. However, there still appears to be an issue concerning thread_future.hpp:

In file included from ../../../../../tools/Common/boost-1.50.0/boost/exception_ptr.hpp:9,

from ../../../../../tools/Common/boost-1.50.0/boost/thread/future.hpp:18, from ../../../../../tools/Common/boost-1.50.0/boost/thread.hpp:24, from myheader.h:48:

../../../../../tools/Common/boost-1.50.0/boost/exception/detail/exception_ptr.hpp:17:2: error: #error This header requires exception handling to be enabled.

My workaround for this is to move the #ifndef BOOST_NO_EXCEPTIONS to the entire scope of thread/future.hpp.

And thanks for the long-awaited progress on this. :-)

Nigel

viboes — Sun, 12 Aug 2012 20:04:47 GMT

Committed in trunk revision 79365.

viboes — Sun, 12 Aug 2012 20:05:35 GMT

Committed in trunk revision 79383.

nstewart@… — Wed, 15 Aug 2012 16:40:58 GMT

Looks good.

viboes — Sun, 09 Sep 2012 08:59:24 GMT

While Boost.Thread compiles now when BOOST_NO_EXCEPTIONS is defined, I have not yet checked disabling exceptions at the compiler side.

In addition Boost.Thread depends on Boost.System and there some issue yet with this library. See #7149: system failed to compile with BOOST_NO_EXCEPTIONS defined when -fno-exceptions is NOT used.

status changed; resolution set

viboes — Tue, 09 Oct 2012 23:40:20 GMT

status assigned → closed
resolution → fixed

You will need to apply the patch attached to #7149.