thread fails to compile with -fno-exceptions

[brbarret@…]

The thread component fails to compile with GCC when -fno-exceptions is specified. The attached patch allows the libraries / tests shipped with boost 1.35.0 to compile. There didn't seem to be a better option to make g++ happy than to just #ifndef out the catch(...) block, as it would otherwise complain about the throw in the block.

[Jonathan Wakely <jwakely.boost@…>]

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.

[Jonathan Wakely <jwakely.boost@…>]

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]

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.

[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.

[Jonathan Wakely <jwakely.boost@…>]

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]

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]

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.

[anonymous]

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@…]

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@…]

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.

[nigels@…]

pthread/thread_data.hpp patch for BOOST_NO_EXCEPTIONS

[nigels@…]

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.

[nigels@…]

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

[nigels@…]

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

[nigels@…]

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.

[nstewart@…]

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

[nstewart@…]

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

[nstewart@…]

Awesome to see this finally closed. Thanks!

[anonymous]

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();".

[nstewart@…]

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

[anonymous]

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

[nstewart@…]

Reopened with suggested milestone of 1.47.0

[anonymous]

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

[viboes]

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

[viboes]

Committed in trunk revision 79347.

[nigels@…]

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]

Committed in trunk revision 79365.

[viboes]

Committed in trunk revision 79383.

[nstewart@…]

Looks good.

[viboes]

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.

[viboes]

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