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

From: Moore, Dave (dmoore_at_[hidden])
Date: 2002-08-06 07:48:16

Peter,

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

This is an interesting perspective...  I think my initial (negative)
reaction to the idea was based on my own "narrow" thinking of asynchronous
function calls being quick, lightweight calls which are best dispatched to
already running threads (pool architectures).

I think the idea of parameterizing the return value has merit on the
"syntactic sugar" side of things, as the user doesn't have to create their
own boost::function just so they can extract a return value - they can still
pass simple function pointers.

Bill's earlier comments to Eric about constraining R to be
copy-constructable, etc. would of course still apply.

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

For thread_groups of these calls, I could envision some algorithm for
composing/combining the return values.  What would we do if some threads
throw() and some don't?  Would partial results be discarded?

We should probably look to the parallel hardware folks for ideas on
accumulating results, handling errors, etc.

Regards,
Dave