From: David Abrahams (dave_at_[hidden])
Date: 2005-08-29 07:24:34
Slawomir Lisznianski <slisznianski_at_[hidden]> writes:
> David Abrahams wrote:
>> My point was that it doesn't matter if people expect that capability
>> when the compiler and/or OS don't provide it.
> Your point was obviously valid, but how was stating it getting us any
> closer to solving the problem at hand (of silent thread death)?
If you are counting on the system to solve the problem for you by
having some "expected behavior" that's not required by the standard,
or worse, required but not broadly implemented, then it would have
prevented you from implementing a false solution.
> What I proposed was for the library to loosen up and let the default,
> platform specific behavior, kick in. The accompanying Boost.Threads
> manual could state "if an exception escapes the thread function, the
> outcome is platform specific".
I would say either implementation-defined or undefined, depending on
whether you want to require each Boost.Threads implementation to
document the behavior. Probably undefined is the only one that will
allow implementations to leave off the catch block altogether.
> If I'm a user who is not satisfied with the "platform specific
> behavior", or simply don't know what that behavior is, I will wrap
> my thread function and make it act one way or another. The important
> point being: the user will have a choice between a compiler supplied
> handler and her own.
> > Arguments about what is "usually commonly expected" are almost always
> > a reflection of the expectation of the person making the argument, and
> > not based on any kind of hard data.
> Leveraging compiler features in under- or non-standardized areas seems
> like a fair objective to me.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk