From: David Abrahams (dave_at_[hidden])
Date: 2005-09-01 09:26:57
Roland Schwarz <roland.schwarz_at_[hidden]> writes:
> David Abrahams schrieb:
>>Not from a portable C++ point-of-view, no.
>>A platform or C++ implementation is free to implement its own
>>swallowing, so there's no guarantee that there will be less error
> I am not sure I got the point, please keep patient:
> Wouldn't this imply that a particular C++ compiler does know about
> threading at a specific platform?
>From an abstract, portable C++ POV that's certainly possible.
> I always was thinking that current compilers are thread unaware at
I'm not sure. I think some may, e.g., protect static initializations.
I know that some have an EH mechanism that's bound to pthread
> Only libraries e.g. built around pthreads made the connection
> between C++ and threading so far.
> Could you please give me an example where this is substantially
> different? I.e. where the ending of a thread will not swallow
> uncaught exceptions?
I don't have one.
> But please don't get me wrong. I am not advocating to remove the
> catch all.
> I can see the potentially undefined behaviour if it were
> removed. I just don't think that it will have a big impact from a
> practical perspective.
> Also I cannot understand how a C++ compiler should be able
> to detect that a thread has ended and call the respective
> process shutdown if there are any uncaught exceptions.
It's known as "compiler magic."
>> You can just put the try/catch in your thread main function and call
>>the shutdown function from there.
> But this would force a user to use platform specific code in his
> program, wouldn't it?
Not unless you think the shutdown function is platform specific. But
anyway, Boost.Thread never promised to protect users from ever having
to write platform-specific code.
> The boost thread does not have a dedicated function for process tear
> down. And I doubt the standard does say anything about process tear
> down in the presence of threads.
Urr, abort(), terminate(), and exit() all come about as close as you
could want to addressing process termination.
> On the other hand the process tear down could be put into the catch all
> clause of the thread proxy. Unfortunately this will be a _big_ change from
> a user perspective.
And having any catch all clause at all will prevent us from reaching
other goals desired by the instigators of this thread.
> What about adding a dedicated process tear down function to the
> library? This function could be called by the user if needed.
What's wrong with what the standard provides?
-- 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