如何解决将来是否会从std :: async返回,并在析构函数中使用launch :: deferred策略块?
在std::async
的描述中说:
如果从
std::future
获得的std::async
没有移出或绑定 引用,std::future
的析构函数将在 完整表达式的结尾,直到异步操作完成为止, 本质上使代码如下同步:std::async(std::launch::async,[]{ f(); }); // temporary's dtor waits for f() std::async(std::launch::async,[]{ g(); }); // does not start until f() completes
(请注意,std :: futures的析构函数 通过对std :: async的调用之外的其他方式获得,永远不会阻止)
该声明令人困惑,并且我不清楚在使用std::launch::deferred
策略的情况下的行为。好的,实验表明它不会被阻塞,但是我想知道标准是否明确表示使用std::async
策略从std::launch::deferred
返回的将来不会在析构函数中阻塞。
这带来了另一个有关默认策略的后续问题:如果std::async
的情况下从std::launch::async
返回的未来在析构函数中阻塞,而在std::launch::deferred
的情况下不会阻塞,如果使用默认(std::launch::async | std::launch::deferred
)策略,则会导致非常不一致的行为。最近,我问到std::async
的语义与默认启动策略:What is the semantics of std::async with automatic (launch::async|launch::deferred) launch policy?的情况,此示例使我更加困惑,并且该模式的适用性(我们不明确知道该策略的平台选择) ,这是非常可疑的。
更新:我发现了针对标准P0701r1的提案,该提案无法完全回答我的问题,但是如果该提案被接受,它将解决阻止/不阻止的歧义阻止析构函数。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。