At 10:50 PM +0300 7/6/06, Peter Dimov wrote:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> 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?