- 主题:boost asio容易误用的一个地方
boost::asio::io_context m_io_context = {};
【 在 z16166 的大作中提到: 】
: 错误写法
: class CMyClass
: {
: ...................
--
FROM 115.193.172.*
能用std尽量用std，boost里一堆HAS_STD_XXX的宏都用起来
【 在 z16166 的大作中提到: 】
: 我现在用的是unique_ptr。等折腾完手头的另一个问题，换回去试试。
: 这个问题更诡异点，在join boost asio的worker线程时会崩，worker线程设为1个也会。目前看起来是个编译环境问题（arm64上musl + gcc + boost），也影响到了m_timer的初始化。
: 跟这个report几乎一样：
: ...................
--
FROM 115.193.172.*
也不是不可以 直接外部stop socket就是硬刹车 里面所有未完成的任务直接按错误代码回呼
死机的最大可能是那个socket本身是个指针 stop以后就被释放了 然后所有callback里如果绑了socket的指针就都出问题了
如果去读asio自带的example 所有的socket几乎都是enable shared from this 然后绑的都是shared ptr
换个思路想 因为是异步代码 除非你有什么机制保证socket这些都是最后才被清理的资源 不然谁使用谁释放的stack逻辑就不成立 那就老实用shared ptr 如果真的执着于运行效率 去弄一个pool
【 在 z16166 的大作中提到: 】
: 别人的库里的一个代码，还好有源码。这个代码也踩了boost asio的坑，比如在worker线程之外的stop ...
--
FROM 115.193.172.*
socket是不是thread safe指socket上的io操作，比如能不能多个同时读取或者同时写入或者同时读写
但是shutdown这种操作不需要，socket本质上就是一个file handle，fstream在close的有要求不能在写入么？更一般的，dtor要求不能抛异常
Callback因为意外shutdown产生的错误有错误代码 这就是为什么回呼函数里带一个error code的参数的原因。你读下Asio自带example里怎么shutdown socket的代码就知道了
【 在 weiwallz 的大作中提到: 】
: enable shared from this的目的是防止async回调的时候，对象已经销 ...
--
FROM 115.192.188.*
Asio是header only的，里面为了优化有很多编译时的编译器参数 你说Asio需要编译是什么情况？如果是底层库里用了Asio 需要用imp模式做打包 不能在头文件里暴露Asio的头文件
【 在 z16166 的大作中提到: 】
: 如果只是执行一个OS的socket句柄的关闭的话，还行。复杂操作就不行了。不过我到现在都没搞明白4楼那个崩溃栈是为啥，当 ...
--
FROM 115.192.188.*