-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]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@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?
<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