Kim Barrett wrote:
[checking cvs] Ah, yes. So you've maintained the old behavior of always calling on_thread_exit() on the way out of thread_proxy(). The email from Roland that I quoted raises the question of whether that's actually needed or even correct, but that's a different issue from the elimination of the annoying catch-all.
Unfortunately I was held off for some time by other tasks, so I did not see this thread earlier. Explanation of the double call: In case the automatic cleanup works the call in the proxy is not really necessary. The cleanup in this case even is called when threads are used that have not been started by as boost:threads i.e. native threads. But this is compiler dependent, and might break when new versions pop up, or e.g on borland. In this case the on_thread_exit call becomes mandatory. I.e. tss still behaves correctly for threads that have been launched via the boost::thread API. So on the one hand I would like to see the original behaviour restored. I agree on the other hand, that it is not very sensible having threads with uncaught exceptions dying silently. But putting it into a guard however is not an ideal solution since it requires, that on_thread_exit must not throw, which is a severe restriction, because on_thread exit is responsible to run the atexit handlers which might even call user provided code. And this might make it harder to find the original source of error if they throw. So, which other solutions are possible: 1) omit the on_thread_exit in case of uncaught exceptions. (and do away with the try clause) 2) rethrow ? 3) emit a debugging message (at least this is why I would want the catch(...) removed) 4) Forcibly shut down the entire process While 1) leaves the issue to the crt library I am not sure if this will give rise to implementation dependent behavior. At least the standard says that terminate must be called when an exception handler cannot be found. This undoubtedly is the case, but on the other hand the standard currently isn't about threads at all. But I think one can reasonably expect that the crt vendor took care of this case. Clause 2) is almost the same than 1) but the on_exit_thread executed. Whether this is a good thing depends. I am inclined to not. Putting a debug message as in 3) only creates overhead. At least the crt already can be expected to take care in a sensible way. And 4) most likely will render the debugger less effective. So my opt. is for 1). Roland