Dave, On Tue, Nov 25, 2008 at 7:57 PM, David Abrahams <dave@boostpro.com> wrote:
on Tue Nov 25 2008, "Neil Groves" <neil-AT-grovescomputing.com> wrote:
Dave,
On Tue, Nov 25, 2008 at 6:05 PM, David Abrahams <dave@boostpro.com> wrote:
I talked to an organization a few days ago that wasn't using Boost.Thread because of the catch(...) clause in the thread launching functions. They wanted the usual Win32 termination behavior (where you get a stack backtrace) instead. While that might seem like a silly reason not to use Boost.Thread, it's legitimate.
The catch clause in the code is a good thing in my opinion because of 15.3.9 in the standard which states: "If no matching handler is found, the function std::terminate() is called; whether or not the stack is unwound before this call to std::terminate() is implementation-defined"
Well, good or not, that makes it required if we want to conform to the upcoming standard. A leaked exception under Win32/MSVC does not cause terminate() to be called. However, it might be good to provide a non-conforming mode for this purpose.
Agreed. It seems that a debugging mode would be desirable. I appear to be in the minority for prefering the catch(...) to be in the code so that stack unwinding is performed and destructors are executed. Perhaps we could implement something on Windows using imagehlp to take a snapshot of the stack and thereby have our destructors executed and capture the stack information?
I typically want my destructors to run, so I prefer to have this catch
block
present. The alternative is to implement catch (...) in all functions run by thread. The disadvantage is, of course, that debugging is more awkward after an unhandled exception. When using Visual Studio I have found it useful to configure the exceptions to stop when thrown, although this might prove impractical for some.
That's fine when you're running under the debugger, but if you want good post-mortem information and/or JIT debugging, you need to leak the exception or use the set_se_handler trick, which -- I think -- only helps for segfaults and the like, not C++ exceptions.
Agreed.
Due to the my perceived necessity to guarantee stack unwinding, I propose that "leaking" the exception is ok if by "leaking" we mean to optionally rethrow.
That's not what I meant.
I didn't think you did really! I just really want my destructors to run!
I told them about several ways to work around that issue, but I think all of them are more hassle and provide a less useful result (to them) than simply letting the exception leak. I wonder if the that would be a conforming implementation, whether a call to terminate() is required, and whether a preprocessor switch to allow exceptions to leak would be a good idea?
Do you mean conforming to the current C++ standard or to a newer thread proposal?
There's no threading in the current standard; I meant the CD.
Of course.
I believe that section 15.3.9 means that either order of stack unwinding and termination is allowable.
I don't know what you mean by that.
I meant that section 15.3.9 allows the std::terminate call to occur in the event of an unhandled exception without unwinding the call-stack, but it also allows stack unwinding followed by std::terminate. This was also why I asked about which standard you were asking about, since I was not sure if you were checking compliance of the exception handling specific parts or the threading parts. I am now though.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost