You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Henry Robinson (JIRA)" <ji...@apache.org> on 2017/06/01 21:49:04 UTC
[jira] [Commented] (KUDU-2028) Async Proxy callbacks cannot capture
non-copyable types
[ https://issues.apache.org/jira/browse/KUDU-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033762#comment-16033762 ]
Henry Robinson commented on KUDU-2028:
--------------------------------------
Ugh, this is harder than I thought: {{std::function}} and {{boost::function}} both require copyable types, so it's impossible to construct a {{ResponseCallback}} from a move-only lambda. All solutions I've seen fake it out with a {{shared_ptr}} somewhere in the mix.
> Async Proxy callbacks cannot capture non-copyable types
> -------------------------------------------------------
>
> Key: KUDU-2028
> URL: https://issues.apache.org/jira/browse/KUDU-2028
> Project: Kudu
> Issue Type: Improvement
> Reporter: Henry Robinson
> Assignee: Henry Robinson
> Priority: Minor
>
> Callbacks that are passed to {{Proxy::AsyncRequest()}} are passed by reference. They are then passed by value into {{OutboundCall()}}, where that copy is saved.
> This means that you can't have a callback that captures a non-copyable type:
> {code}
> unique_ptr<Foo> my_foo = make_unique<Foo>();
> auto cb = [f(move(my_foo))]() {
> };
> proxy->AsyncRequest("method", req, response, controller, cb); // <-- error, missing copy c'tor for unique_ptr<Foo>
> {code}
> This is a sometimes useful idiom for passing ownership of something into the callback, where it can get destroyed some time in the future, after the caller has ceased to exist.
> A solution would be for {{AsyncRequest()}} (and its generated wrappers) to take a {{ResponseCallback}} by value, and to {{move()}} it until it was copied. This kind of transformation has its drawbacks (if for some reason the parameter doesn't get copied, it is more expensive than pass-by-reference), but seems a reasonable tradeoff here.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)