Boost logo

Boost :

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-06 12:59:39


Peter, but the argument that has been made is that join doesn't have to be
called, ever.

What you mentioned makes sense if terminate () is the behavior that is
desired. I'm still a proponent of making termination a boolean state in the
thread object.

Has anyone addressed whether an exception can only be caught only once or
whether it is possible for multiple threads waiting on join to receive the
exception? It seems that multithreaded exceptions don't have a one-to-one
relationship between catcher and thrower, it's many-to-one.

----- Original Message -----
From: Peter Dimov
Newsgroups: gmane.comp.lib.boost.devel
Sent: Tuesday, 2002:August:06 1:42 PM
Subject: Re: 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());

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

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

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk