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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-08-06 07:17:52

From: "Moore, Dave" <dmoore_at_[hidden]>
>
> Eric Woodruff:
>
> Personally, I don't think advanced_thread should compose a boost::thread
or
> derive from it. boost::thread is fairly impotent. If the advanced_thread
was
> named asyncronous_function_adapter, boost::thread would be depreciated, as
I
> said earlier. (Of course, for the platform neutrality,
> asyncronous_function_adapter would have to dervive from a protected
private
> base class where the platform-specific code would reside.)
>
> However, removing the non-templated (publically accessible) base type
would
> probably introduce complexity in the thread pool (which would again need
to
> be renamed if the thread was thrown out). I suggest instead putting
> boost::thread in a sub namespace and frowning at its use.
>
> **Reply**
>
> Yes, but there are of course many ways to use threads in application
designs
> besides asynchronous function calls.  Asynch function calls are a useful
> mechanism, but aren't a universal replacement for  a general purpose
> threading class.

I'm with Eric here. Async function call in the advanced_thread sense is a
proper superset of the general purpose threading class (boost::thread
sense.) That is,

template<class R> class thread
{
public:
    thread(function0<R> f);
    R join();
};

completely subsumes thread<void>, which is what boost::thread currently is.

Roll-your-own thread<R> is possible, but I definitely don't agree with its
"triviality", especially when a thread group (performing a computation in
parallel) needs to be joined and the results combined. (Having threads that
play with standard library containers could help, too, but I digress.)

Now, if you accept thread<R>, the exception handling kind of follows
naturally. It is a postcondition of

R join();

that it returns the return value of the expression 'f()'. If f() throws,
there is no return value, and therefore join() must also throw; it cannot
return.

The enumerated exception list is questionable, though. I'd specify join() to
throw an implementation-defined exception when f() throws. With compiler
magic, it can even be a copy of the real thing. Without, well, it can at
least preserve std::exception::what().