Boost logo

Boost :

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2004-02-08 16:11:03


Jeff Garland wrote:
> On Sun, 08 Feb 2004 11:23:37 -0500, David Abrahams wrote
>
>>Christopher Currie <christopher_at_[hidden]> writes:
>>
>>
>>>Slawomir Lisznianski wrote:
>>>
>>>>Are there any plans to support handling of exceptions thrown during
>>>>joinable thread execution? I recall Usenet discussions with proposals
>>>>varying from Futures to throwable join():
>>>>try {
>>>> thread.join();
>>>>}
>>>>catch (std::runtime_error& e) {
>>>> ...
>>>>}
>>>>Any ideas?
>>>
>>>Doesn't this require a certain amount of compiler support?
>>
>>Yes.
>
>
> Why? Corba throws user exceptions across remote procedure calls without
> changes to the c++ compiler (of course there is an IDL compiler).

I see two different uses here for exceptions that seem to get lumped
together: one is the controlled stack unwinding, i.e. the typical usage
of exceptions in a single thread / single address space.
The other is a means of communication that could even be used for
'higher level call stacks' such as in CORBA.

The case of CORBA is particularly interesting as it tries to let the
user believe he runs a conventional synchronous work flow when the ORB
really deals with asynchronous message calls internally: when you call
a method that (internally) gets dispatched to another address space
the ORB blocks the current thread until it gets back the result (either
return value or failure, which will be mapped back into an exception in
the C++ mapping).

So the question seems to me: what do you gain in a multi-threaded
application to report thread execution failure as an exception to the
main thread (the one calling 'join') ?
While it seems entirely possible to declare some exception types that
are throwable across threads (in the same way there are CORBA::Exceptions
that can be exchanged across ORBs), I don't really see why a generic
threading library should provide such a facility.
It can always be added on a higher level that wraps the 'join()' call.

Regards,
                Stefan


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