Re: [boost] Re: Re: Threads & Exceptions

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-06 13:16:45

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, August 06, 2002 12:42 PM
Subject: Re: [boost] Re: Re: Threads & Exceptions

> From: "William E. Kempf" <williamkempf_at_[hidden]>
> >
> > If you can devise a method that relies only on copy construction and
> allows
> > reference types I'd love to see it.  I'd have no objections at that
point.
>
> See George Heintzelman's post. The general idea is that
>
> R r;
>
> is replaced with
>
> char r[sizeof(R)];
>
> (except that it needs to be properly aligned, so we'd need a
> boost::aligned_storage) and
>
> r = f();
>
> is replaced with
>
> new(&r) R(f());

OK, I can follow this.  The alignment issue has been what's scared me the
most here.

> References would need to be converted temporarily to pointers, but _seems_
> possible.

Through black magic, yeah ;).  I can try and see if I can devise a solution
here, though I'm not sure I've got the expertise to do so.

> > > terminate() is invoked when there is no matching exception handler. If
> > > join() magically transports exceptions across thread boundaries, the
> > > exception thrown in main() will be caught by the join()ing thread, and
> > > things are fine and dandy.
> >
> > How can they be caught in the joining thread if terminate() is called,
as
> > the standard says it must be?
>
> Fair point, but how many real world programs leave exceptions uncaught in
> order to call terminate()?

I'd say a good number of them don't catch the exception.  Maybe the intent
wasn't specifically to get terminate() to be called, but that's the result.

> > > Unfortunately, when there is no join(), the uncaught exception must
> > > terminate the process, but we don't know in advance whether there will
> be
> > a
> > > join() sometimes in the future!
> >
> > True, so the issues are related and both issues are terrible, IMHO, and
> are
> > the crux of why I don't think it's appropriate to propogate exceptions
out
> > of a thread.
>
> There are definitely some good arguments for calling terminate() when a
> thread allows an exception to escape; on the other hand, intra-thread
> exceptions are an useful form of communication, just like with ordinary
> function calls. Difficult choice.

I don't think the choice is difficult from a library stand point.  The
issues are too complex and too application specific for passing exceptions,
so as long as I don't somehow prevent the user from doing this themselves
(which I don't think would even be possible), then I'll choose to
terminate().

> A hybrid solution is also possible, if a thread keeps track of its
handles.
> If an exception escapes, and no handles are alive, nobody can join() and
> it's terminate() time.
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>