RE: [boost] Re: future of boost.threads

From: scott (scottw_at_[hidden])
Date: 2004-02-09 20:34:09

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]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