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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-06 10:05:33

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, August 06, 2002 7:59 AM
Subject: Re: [boost] Re: Re: Threads & Exceptions

> From: "Moore, Dave" <dmoore_at_[hidden]>
> >
> > Bill's earlier comments to Eric about constraining R to be
> > copy-constructable, etc. would of course still apply.
>
> I think that the implicit requirement that 'R' is a valid function return
> value might be enough.

I don't think so.  There's no requirement for return values to be default
constructable, but that's the only manner in which I can see to implement
this.  The underlying C APIs don't allow for the return of an arbitrary
type, and so I'll have to employ an "out value" implementation, which means
creating and storing an instance of R in the thread state.

> > For thread_groups of these calls, I could envision some algorithm for
> > composing/combining the return values.
>
> std::accumulate? Or we can even reuse signal combiners. :-)
>
> >  What would we do if some threads
> > throw() and some don't?  Would partial results be discarded?
>
> Seems logical. If you perform the same computation sequentially and a
> "segment" throws, partial results are discarded.

I think that would have to be a decision left to the user.  I would think
that most computations would at best be inaccurate if partial results were
used, and more likely would simply be wrong.  I'd expect most use cases
would want the whole computation to fail with an exception (assuming one
agrees with passing exceptions in this manner).

Bill Kempf