[boost] Re: Re: Re: Boost.threads: interthread exception conveyance

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-24 13:15:49

Termination of the thread is implicit with any exception thrown beyond the
user's boundary -- irregardless the exception policy used.

----- Original Message -----
From: David Bergman
Newsgroups: gmane.comp.lib.boost.devel
Sent: Saturday, 2002:August:24 13:46
Subject: RE: Re: Re: Boost.threads: interthread exception conveyance

I hope this rerun of The Meta Thread is better than the original...

My interpretation of the latest comments by Bill (= Bill Kempf) was that
uncaught exceptions should cause a termination, but not of the process,
but instead of the thread, using some "terminate_thread". There would
still be no attempt to duplicate that exception for catching in other
threads (joiners or not). After that comment, the "tumult" ceased, and
the first iteration of the frensic thread was ended. That I regarded as
a silent consensus (which was probably totally wrong...).

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Eric Woodruff
Sent: Saturday, August 24, 2002 12:41 PM
To: boost_at_[hidden]
Subject: [boost] Re: Re: Boost.threads: interthread exception conveyance

It doesn't return. (In the case of the no_exceptions policy, the
application has terminated anyway.) That is not to say that threads with
no return type cannot or should not propagate exceptions. I understand
that some rely on the fact that join () returns a value to assume that
the user will put a proper try/catch around it -- or even call join ()
to not let the exception die. But it is still a user responsibility and
the user can choose to throw exceptions why any return type.

----- Original Message -----
From: Peter Dimov
Newsgroups: gmane.comp.lib.boost.devel
Sent: Saturday, 2002:August:24 12:19
Subject: Re: Re: Boost.threads: interthread exception conveyance

From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
> ">   q19) In reality why wouldn't q5's technique for handling an
uncaught
> exception thrown in a nonjoinable t apply equally well to handling an
> uncaught exception thrown in a joinable t as well?  (Why have two
techniques
> instead of one?)<
>
> To support threads that are able to return a value."
>
> The threads can support return values without exceptions, they are
> orthogonal, but necessary, concepts.

What value do you return when the thread function has ended with an
exception?

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost