水木社区手机版
首页
|版面-C++程序设计语言(CPlusPlus)|
新版wap站已上线
返回
1/1
|
转到
主题:原来这个async的返回值阻塞的问题大佬们争了这么久。。。
楼主
|
libgcc
|
2020-09-20 01:30:19
|
只看此ID
https://stackoverflow.com/questions/23455104/why-is-the-destructor-of-a-future-returned-from-stdasync-blocking
尤其是Herb Sutter这位大佬最后忍无可忍直接提议废除std::async。。。
所以最后结果怎么样了啊,怎么有的说14已经改了有的说没变
--
FROM 171.83.95.*
1楼
|
libgcc
|
2020-09-20 01:38:01
|
只看此ID
话说回来当我发现这个async返回值阻塞的时候,我也觉得std::async是真没啥卵用,直接用thread还省心
--
FROM 171.83.95.*
2楼
|
allegro
|
2020-09-20 01:46:30
|
只看此ID
这是个烂坑。
--
FROM 158.140.1.*
3楼
|
hongdiao
|
2020-09-20 14:48:12
|
只看此ID
不是非常明白在那一种情况下会遇到这个坑。我的习惯是在需要得到返回值的时候使用future,在不需要得到返回值或者需要精确控制线程的时候就使用thread。 如果这样的话就不太会遇到这个坑吧? 因为如果是在需要得到返回值的时候使用future,即使是从std::async返回的future, 你为了得到返回值一定会在上面手工调用get()。 在这种情况下future的析构函数就不会阻塞啊。 当然也有一些特殊情况比如在get()之前抛出了异常等等,不过这时候抛出的异常更值得你担心吧。。
反过来看std::future本身的定义,可以清楚的看到这个类就是为了得到返回值而设计的。它的大部分成语函数也都是为了得到返回值设计的。 没有一个成员函数给用户提供了所谓的“启动之后不管了”的选项。 你非要抬扛说返回void之类的那我也不想争论,但是毕竟人家设计这个不是干这个用的,这种情况还是老老实实用thread的不好吗非要强行用future干嘛?
--
FROM 122.115.229.*
4楼
|
speedboy2998
|
2020-09-21 12:36:56
|
只看此ID
非常不明白,委员会为啥不把facebook folly的那套FUTURE引入到STL里面去。。
【 在 hongdiao 的大作中提到: 】
: 不是非常明白在那一种情况下会遇到这个坑。我的习惯是在需要得到返回值的时候使用future,在不需要得到返回值或者需要精确控制线程的时候就使用thread。 如果这样的话就不太会遇到这个坑吧? 因为如果是在需要得到返回值的时候使用future,即使是从std::async返回的future, 你为了得到返回值一定会在上面手工调用get()。 在这种情况下future的析构函数就不会阻塞啊。 当然也有一些特殊情况比如在get()之前抛出了异常等等,不过这时候抛出的异常更值得你担心吧。。
: 反过来看std::future本身的定义,可以清楚的看到这个类就是为了得到返回值而设计的。它的大部分成语函数也都是为了得到返回值设计的。 没有一个成员函数给用户提供了所谓的“启动之后不管了”的选项。 你非要抬扛说返回void之类的那我也不想争论,但是毕竟人家设计这个不是干这个用的,这种情况还是老老实实用thread的不好吗非要强行用future干嘛?
--
FROM 218.76.62.*
5楼
|
Friz
|
2020-09-21 20:55:31
|
只看此ID
这么巧, 我在坑底等谁来拉我出来
话说有最简单的方式出坑吗
幸好场景比较简单,现在能想到的就是弄个全局future pool, 不destruct
等程序退出让它自己退出
【 在 libgcc 的大作中提到: 】
:
https://stackoverflow.com/questions/23455104/why-is-the-destructor-of-a-future-returned-from-stdasync-blocking
: 尤其是Herb Sutter这位大佬最后忍无可忍直接提议废除std::async。。。
: 所以最后结果怎么样了啊,怎么有的说14已经改了有的说没变
--
修改:Friz FROM 112.10.88.*
FROM 112.10.88.*
1/1
|
转到
选择讨论区
首页
|
分区
|
热推
BYR-Team
©
2010.
KBS Dev-Team
©
2011
登录完整版