Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-08-06 12:42:08

From: "William E. Kempf" <williamkempf_at_[hidden]>
> If you can devise a method that relies only on copy construction and
> 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());

References would need to be converted temporarily to pointers, but _seems_

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

> > Unfortunately, when there is no join(), the uncaught exception must
> > terminate the process, but we don't know in advance whether there will
> a
> > join() sometimes in the future!
> True, so the issues are related and both issues are terrible, IMHO, and
> 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.

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at