- 主题:shared_from_this 这种设计多吗?
主要是因为异步任务的生命周期管理的问题,不用shared_from_this,除非你写一个全局的任务管理器,不然在程序结束析构的,不知道任务是否完成
--
FROM 115.192.190.*
有管理需求就有性能损耗,asio的executor,或者能看到的广泛使用的executor都没有设计任务队列管理功能
我猜原因大概是因为任务队列管理这块里有太多的用户定制需求,有些情况下,需要post到队列里的任务全部完成,有些需要cancel没有开始执行的,继续执行已经在执行的,有些需要按条件cancel,按c++的设计思路,这块肯定是需要用户自己写一个全局的任务管理器
【 在 z16166 的大作中提到: 】
: 确实是
: 我现在有个程序只有单例类(模块类)才会向也是单例类的executor(线程池)post任务过去,
: 程序初始化时最先初始化executor,程序结束前要最先停掉executor(不接受新任务,等待已经提交的任务执行完,但executor的this指针并不在这个时候销毁),防止它还在引用别的单例类的this指针。
: ...................
--
FROM 115.192.190.*
特化场景和普通化场景下的效率肯定是不一样的
特化场景有特定的需求和结构,肯定能做优化,特化和普通化的平衡本身就是库作者最费脑子的一部分
【 在 tortelee 的大作中提到: 】
: 你们平时用sharedptr多么?
: 我们有一套自定义语言,自动管理类之间的reference关系和析构啥的。
: 平时基本不用sharedptr
--
FROM 115.192.190.*
gpt的回答有点同鸡讲鸭了
shared_from_this的核心,是shared,不是common interface。换成人话就是说,executor在执行一个异步任务以后,需要继续把这个object post到队列里执行等待后续的异步回应,这个操作需要要求这个object在后续异步回应到达的时候还存在,那么怎么保证,要么有一个全局的object管理器,要么这个object是个shared_ptr从自己生成一个。显然从自己copy一个或者从自己move出一个有很大的开销和风险,所以多一个shared_from_this()的接口
【 在 z16166 的大作中提到: 】
: 有些截图软件支持滚动截屏,FarStone Capture之类的,截了后按pagedown键向下翻页选中需要的区域,复制到画笔里存盘。
: Chrome自带的截屏功能不如这个。
: chatgpt提到的这个type erasure有点意思
: ...................
--
FROM 115.192.190.*