- 主题:boost asio容易误用的一个地方
也不是不可以 直接外部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.*
新一点的想法应该是尽量move，但容易搞不清
【 在 ziqin 的大作中提到: 】
: 也不是不可以 直接外部stop socket就是硬刹车 里面所有未完成的任务直接按错误代码回呼
:
:
: ...................
--
FROM 114.242.248.*
enable shared from this的目的是防止async回调的时候，对象已经销毁了，所以用一个shared_ptr 捕获到回调的lamda里面，这样能保证回调执行的时候，对象依然还在
但是，从另一个线程去stop socket则是另外一码事，这样做的前提是所有的boost socket操作都是线程安全的，但是实际上这个没有明确保证，所以还是不建议从另一个线程去stop socket
【 在 ziqin 的大作中提到: 】
: 也不是不可以 直接外部stop socket就是硬刹车 里面所有未完成的任务直接按错误代码回呼
:
: 死机的最大可能是那个socket本身是个指针 stop以后就被释放了 然后所有callback里如果绑了socket的指针就都出问题了
: ...................
--
FROM 123.168.94.*
如果只是执行一个OS的socket句柄的关闭的话，还行。
复杂操作就不行了。
不过我到现在都没搞明白4楼那个崩溃栈是为啥，当时编译出来的可执行程序，每次运行时这个崩溃是必现的。
但是把boost库和一个第三方库又重新编译覆盖后，这个问题无法重现了。
【 在 weiwallz 的大作中提到: 】
: enable shared from this的目的是防止async回调的时候，对象已经销毁了，所以用一个shared_ptr 捕获到回调的lamda里面，这样能保证回调执行的时候，对象依然还在
: 但是，从另一个线程去stop socket则是另外一码事，这样做的前提是所有的boost socket操作都是线程安全的，但是实际上这个没有明确保证，所以还是不建议从另一个线程去stop socket
:
--
修改:z16166 FROM 221.218.163.*
FROM 221.218.163.*
要我的话，我就把io_context::io_context()和io_context::~io_context()加上断点，然后看看崩的时候，到底是还没创建io_context，还是因为某种原因（也许其依附的对象不在了），io_context已经不在了
【 在 z16166 的大作中提到: 】
: 如果只是执行一个OS的socket句柄的关闭的话，还行。
: 复杂操作就不行了。
:
: ...................
--
FROM 123.168.94.*
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.*
boost的socket是封装过的对象，不是一个简单的fd，在不同线程对同一个对象操作，自然需要考虑是否线程安全
boost asio 1.78 chat_client. cpp里面关闭socket恰恰就是通过post lamda到io context进行的，也就是关闭操作是和读写操作在同一个线程，而不是直接跨线程执行关闭操作
【 在 ziqin 的大作中提到: 】
: socket是不是thread safe指socket上的io操作，比如能不能多个同时读取或者同时写入或者同时读写
:
: 但是shutdown这种操作不需要，socket本质上就是一个file handle，fstream在close的有要求不能在写入么？更一般的，dtor要求不能抛异常
: ...................
--
FROM 223.104.194.*
代码很简单，就是顶楼里的那种写法，而且崩溃栈就是4楼的，这个时候在构造，是不可能析构的，只能是没构造/没初始化。
gdb没那么好用，我用thread apply xxx bt查看别的线程的栈，经常卡住不返回，gdb 12.1.
跟msvc或者windbg调试比，差得太远
【 在 weiwallz 的大作中提到: 】
: 要我的话，我就把io_context::io_context()和io_context::~io_context()加上断点，然后看看崩的时候，到底是还没创建io_context，还是因为某种原因（也许其依附的对象不在了），io_context已经不在了
:
--
修改:z16166 FROM 221.218.163.*
FROM 221.218.163.*
说起 shutdown()，现有操作系统对于 shutdown, flush, close 的处理真是非常之烂。只有异步版本的 read(), write()，却没有异步的 open(), flush() 和 close() 也不知道什么时候才能解决。
【 在 ziqin 的大作中提到: 】
: socket是不是thread safe指socket上的io操作，比如能不能多个同时读取或者同时写入或者同时读写
: 但是shutdown这种操作不需要，socket本质上就是一个file handle，fstream在close的有要求不能在写入么？更一般的，dtor要求不能抛异常
: Callback因为意外shutdown产生的错误有错误代码 这就是为什么回呼函数里带一个error code的参数的原因。你读下Asio自带example里怎么shutdown socket的代码就知道了
: ...................
--
FROM 59.60.25.*