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

From: scott (scottw_at_[hidden])
Date: 2004-02-10 15:57:55

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Victor A. 
> Wagner, Jr.
> Sent: Tuesday, February 10, 2004 7:17 PM
> To: Boost mailing list
> Subject: RE: [boost] Re: future of boost.threads
> 
> 
> 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?
> > >

<snip>

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

this thread is quite complex. a good chunk of that is probably
attributable to "sprawl" which i suspect i have contributed to.

i now understand (i hope) the original question to be specifically
related to the handling of exceptions at the point of "join".

if boost can formalize the behaviour at this point using facillities
such as typelists then i'm happy with that (impressively staggered
would be closer to the truth).

if i understand boost::threads well enough then my answer to the
original question is yes, it is the right behaviour and yes
it is semantically sensible. some kind of typelist specification
seems complex, but also consistent (with existing exception model)
and powerful.

i'm guessing there will be "normal default" behaviour where no typelist
is given and that this behaviour will be manifested in the joining
thread, i.e. the worker thread should not "fall out the bottom" due
to passing of "bad" code (the functor). i'm happy to leave implementation
of all that to the gods :-)

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

not offended. concerned at most :-) concerned about blurring
of the definition of what an exception is.

very comfortable with the emerging "error handling model for boost::thread
join". the new model involves the throw+catch of one exception and
a related (propagated) throw of a new, distinct exception.

cheers,
scott