[boost] Re: Re: future of boost.threads

From: Sam Partington (Sam.Partington_at_[hidden])
Date: 2004-02-10 10:55:37

On Tue, 10 Feb 2004 15:59:35 +0200, Peter Dimov <pdimov_at_[hidden]> wrote:

> Alexander Terekhov wrote:
>> David Abrahams wrote:
>> [...]
>>>> thrown (or may be something equivalent to 'unexpected'). If it is
>>>> derived from a declared one, it will be sliced.
>>>
>>> Is everyone convinced that propagating the exception into the joining
>>> thread is the right behavior or even semantically sensible?
>>
>> I'm convinced that propagating *unexpected* exceptions into the
>> joining thread is totally wrong and insensible.
>
> Maybe, for some meaning of "unexpected".

I think it all depends on the context.  If you are doing multithreading in 
the traditional sense then yes, propogating the exception is odd.

But another type of multithreading is one which Boost.Threads encourages, 
and that is calling a function synchronously to the main thread of 
execution.

It seems only a logical progression to allow the user access to the return 
value of the called function, and you can't do that (IMO) without 
propogating an exception of some sort in the situation where there is no 
resurn value.  Why not give the user the option of how an exception is 
propagated.  It won't hurt the purists at all because they can easily 
carry on using boost::thread which will not propagate exceptions.

This is something I've often emulated by passing reference's to thread 
functions, and I would find a helper to do this useful in the real world 
frequently.

That said, I don't think that boost::thread should be changed to add this 
capability, boost::thread implies the traditional type of multithreading 
to me.  I've implemented a class async_call that does basically what 
Victor suggested, implemented as a wrapper around boost::thread.

Use :

int f();

try
{
        async_call<int [, my_exception [, ...]]>	async_f(f);
        int x = async_f.result();	
}
catch (my_exception e)
{
        // ...
}

NOTE: In the event of an exception not listed being thrown by the thread 
function, std::bad_exception is currently thrown, I'm not sure if that is 
ideal behaviour or not.

Sam