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

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
>>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