From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-08-28 10:31:36
Michael Glassford schrieb:
>Slawomir Lisznianski wrote:
>>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?!
m_thread = reinterpret_cast<void*>(_beginthreadex(0, 0, &thread_proxy,
¶m, 0, &m_id));
The only thing the catch all clause is doing is call the (somewhat
on_thread_exit() function on the windows platform, which currently only
for TSS cleanup. Not sure about MPTASKS.)
Removing the catch all at this point wouldn't change anything. In
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
2) To stop unescaped exceptions to slip through, one simple should wrap
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
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,
the call to on_thread_exit.
So my recommendation is to leave things as they are, since they 1)
much and 2) give an additional layer of tls leakage protection.
Please correct me if I am on the wrong track.