Re: [boost] [thread] Bug sprint: #2100 thread fails to compile with -fno-exceptions

Subject: Re: [boost] [thread] Bug sprint: #2100 thread fails to compile with -fno-exceptions
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2009-11-24 17:32:39

Vicente Botet Escriba <vicente.botet_at_[hidden]> writes:

> Ticket description: "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." from
> https://svn.boost.org/trac/boost/ticket/2100
>
> Hi, 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.

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.

As you say, Boost.Thread has not been designed to work without
exceptions. In most cases this is not a problem, but interruption relies
on exceptions to work properly. I'm therefore inclined to think that
interruption should not be available with exceptions disabled, in which
case this code can be masked with a #ifdef

What do you think?

Anthony
-- 
Author of C++ Concurrency in Action | http://www.stdthread.co.uk/book/
just::thread C++0x thread library   | http://www.stdthread.co.uk
Just Software Solutions Ltd         | http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976