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

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-08-28 10:31:36

Michael Glassford schrieb:

>Slawomir Lisznianski wrote:
>  
>
>>Hello,
>>
>>I find the catch(...) clause in the thread_proxy function (thread.cpp)
>>causing more harm than good. 
>>    
>>
>
>Does anyone have any comments on this? Support or objections?
>  
>

I am somewhat surprised by the discussion.

1) How could a user function ever "wrap the code" at the thread_proxy level?
There is nothing below on the stack?!
Also see:
    m_thread = reinterpret_cast<void*>(_beginthreadex(0, 0, &thread_proxy,
                                           &param, 0, &m_id));

The only thing the catch all clause is doing is call the (somewhat 
superfluous)
on_thread_exit() function on the windows platform, which currently only 
is used
for TSS cleanup. Not sure about MPTASKS.)
Removing the catch all at this point wouldn't change anything. In 
particular this
would not stop unescaped throws from silently disappearing. An ending thread
also does not normally stop the entire process doesn't it?
I think the catch all is an artifact from the time before the below
DLL_THREAD_DETACH was discovered.

On windows the on_thread_exit is called by the operating system in 
either case:

            case DLL_THREAD_DETACH:
            {
                on_thread_exit();
                break;
            }

2) To stop unescaped exceptions to slip through, one simple should wrap 
the user
thread function with whatever clause is appropriate. And again I don't 
think it is too bad to
forget the re-throw after a catch all at this stage. The on_thread_exit 
will simply
be called later on. But wait, to be honest, there might be a difference: 
Depending on what
the destructors of tls variables are doing, the C runtime library might 
be left with private
leaking tls variables. Supported by the last observation the catch all 
at the thread proxy
level simply is kind of a safeguard to omit this case.
As I see it a user function always could catch all and not rethrow, 
thereby short-circuiting
the call to on_thread_exit.

So my recommendation is to leave things as they are, since they 1) 
wouldn't change
much and 2) give an additional layer of tls leakage protection.

Please correct me if I am on the wrong track.

Regards,
Roland