Roland Schwarz <roland.schwarz@chello.at> 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 masking.
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 all?
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 cancellation.
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 am.
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