Re: [boost] [Boost.Thread]: consider removing catch(...) from thread_proxy

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-09-01 01:12:58

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? I always was thinking that current
compilers are thread unaware at all? 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?

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.
This also cannot be delegated to the operating system, since
this would imply that any ending thread will tear down the
process, which obviously cannot be true. Operating
systems are not exception aware, are they? (Windows is
an exception here, but the exception mechanism is different
from C++ exceptions.) Consequently uncaught exceptions
will silently disapear (swallow?).

>>What I see as a technical problem is how you would be able to
>>force a process shutdown from the context of a thread? Could you
>>please try to sketch how this could be done?
>
> 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?
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.

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.

What about adding a dedicated process tear down function to the library?
This function could be called by the user if needed.

Regards
Roland