[cpp-threads] Asynchronous Function Proposal

Lawrence Crowl Lawrence at Crowl.org
Mon Jun 1 19:57:15 BST 2009


On 6/1/09, Howard Hinnant <hinnant at twcny.rr.com> wrote:
> I agree with Peter's comments regarding collapsing the number of
> signatures, though he did a better job of it than I would have.
> At the very least we don't need:
>
> async(fully_threaded policy, F f);
> async(fully_threaded policy, F&& f, Args&&...);
>
> Just one or the other.  The first if you want to go with Herb's
> suggestion, else just the second.
>
> Either by value (F) or by rvalue ref (F&&) will work, but if the
> latter you probably want to work decay into the effects clause
> similar to that suggested by:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929
>
> or
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817
>
> The use of the decay trait enables one to get the "decay behavior"
> for things like string literals.
>
> > Requires: F and each type Ti in Args shall be CopyConstructible if an
> > lvalue and otherwise MoveConstructible.
>
> I believe MoveConstructible is sufficient and should be specified
> with concepts.  The requirements you're trying to specify (how
> to bind an argument to the parameter) are the caller's concern
> and not the async function's concern.  But async is going to
> need to move construct from the host thread's parameter into
> a bit of memory that the child thread (and future) can access,
> so needs MoveConstructible there.

For the record, I copied the wording from std::thread construction.
While I have no strong feeling on the form of passing parameters,
I think it is important to maintain an interface that is consistent
with std::thread.

If the above chnage is valuable, can and should we apply it to
std::thread as well?

-- 
Lawrence Crowl



More information about the cpp-threads mailing list