-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Stefan Seefeld Sent: Tuesday, February 10, 2004 1:54 PM To: Boost mailing list Subject: Re: [boost] Re: future of boost.threads
David Abrahams wrote:
Is everyone convinced that propagating the exception into the joining thread is the right behavior or even semantically sensible?
I'm not.
For me exceptions are conceptually associated with call stacks. While I can see a generalization of this concept to be valid in environments such as CORBA where a simulation of a synchronous call graph is provided, I think the situation in multi-threaded environments is quite different.
If someone wants to use multi-threading and make it look as a single call stack from the outside, he can always add translators that add exception marshalling on a higher level. I don't think a low level generic threading library should care about that.
i think the same. exceptions result in call unwinding and eventually being caught, or "falling out the bottom". activities tightly bound to the call stack. anything that attempts to "propagate" exceptions across threads would be doing something distinct to what the C++ spec describes, i guess. would it be "more correct" to allow a thread to be notified of an exception in another thread? at which point it could throw (a completely distinct) exception; along the lines of "throw trusty_worker_barfed". the significant difference being that the new exception does not attempt to assume the type+value of the original exception. preserves definition of exception. allows a thread (or threads) to respond to exceptional activity in another and sidesteps the issue of copying (i.e. slicing). at the obvious cost of actual type+value of the original. a "lossy propagation" model? BTW: should the propagation question extend to threads in other processes? except for the obvious difficulty of transfer to another address space it would seem a relevant question with all the refs to ACE+TAO SW