Re: [boost] [thread] catch(...) removed

From: Kim Barrett (kab_at_[hidden])
Date: 2006-07-06 23:41:26

At 10:50 PM +0300 7/6/06, Peter Dimov wrote:
>David Abrahams wrote:
>>  "Peter Dimov" <pdimov_at_[hidden]> writes:
>>
>>>  Pedro Lamarão wrote:
>>
>>>>  Shouldn't there be some sentry object then, with that
>>>>  "on_thread_exit()" thing called by the destructor?
>>
>>>  If you allow an exception to escape from your thread function, the
>>>  default behavior is for the runtime to call terminate(), so a missing
>>>  on_thread_exit is the least of your worries. :-)
>>
>>  Well, let's not forget that terminate() is a form of orderly shutdown.
>
>It's easier to move the on_thread_exit call to a destructor than to argue
>about the precise meaning of orderly shutdown, so that's what I've done. :-)

Quoting from Roland Schwarz, 8/28/05: "consider removing catch(...)"

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

Thus, assuming I understood Roland correctly, on_thread_exit() was
being called twice on Windows in the case of unhandled exceptions in a
thread, once in the catch-all under discussion, and then again in the
above clause (whose location I haven't researched), the latter making
the former unnecessary. The same reasoning might lead one to conclude
that this clause makes the on_thread_exit() in the thread destructor
that Peter is adding also unnecessary. I don't know anything about
Windows at this level, so can't evaluate the correctness of this
reasoning though. BTW, I also have no idea what the consequences of
multiple calls to on_thread_exit() might be, but Peter might want to
consider that before making the destructor change. [Oh, I see the
destructor change is already in cvs.]

One more question: is this (IMO) bug fix going to make it onto the
1.34 branch? Please?