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

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2004-02-10 01:17:11

At Monday 2004-02-09 18:34, you wrote:

> > -----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.

consider the call to join()
what's the big hoo-haw about it getting some information back from the 
thread? and if there's info, then there might be an exception as part of it.

>anything that attempts to "propagate" exceptions across
>threads would be doing something distinct to what the
>C++ spec describes, i guess.

Hey, if you seem to be offended by this, how about a NEW function called 
wait_for_and_report_results(somethreadhandle) ??
would it be ok for that function to throw?  Why not?

It's beginning to look like there are different models that all use 
"threading" as an implementation technique.  These models apparently also 
differ on what should happen if a "thread goes bad".

I've been doing embedded systems since 1971 "crashing" the computer is NOT 
an acceptable answer.  Short of catastrophic failure of the computer system 
itself, all errors must be given to the program in one fashion or another 
so that it can attempt to recover.

>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
>
>
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr.      http://rudbek.com
The five most dangerous words in the English language:
               "There oughta be a law"