有关LostConnectionCallback的一些问题

[Numendacil]

其实是代码上的一些疑问，如有打扰到十分抱歉

在WebSocketClient中，RecvLoop在执行到LostConnectionCallback时会被阻塞住，直到函数返回时再检测WebSocketClient::Status并退出(WebSocketClient.cpp)。这个时候如果LostConnectionCallback中调用类似于Connect这样的函数的话好像WebSocketClient::Status会被设置成open从而导致原RecvLoop并不会退出？

感觉应该可以在mirai_bot.cpp里把OnLostConnection改成单独分配一个线程用来执行回调函数以防止阻塞或者在WebSocketClient中把shutdown放在LostConnectionCallback后面执行？

[cyanray]

WebSocketClient 是随手写的玩意，代码乱的我自己都看不懂了。 我检查了下，应该不会有这种问题。

在 WebSocketClient 库里，每到调用 LostConnectionCallback 的分支，都会跟着 break;(这个 break 看起来应该改成 return? ) 或者 return; 。这就意味着，LostConnectionCallback 返回之后，逻辑上保证了 RecvLoop 也会返回（所以不会因为检测到 WebSocketClient::Status 再次变成 Open 就没法退出了，根本没有检测了，直接break或者return了 ）。所以在这个库的 LostConnectionCallback 里调用 Connect 是安全的。

在 mirai-cpp 里，好像真的会有大问题。每次执行 MiraiBot::Connect 都会销毁掉原来的 pimpl 对象。pimpl 对象里包含一个 WebSocketClient 对象。但是此时这个对象的 WebSocketClient::LostConnectionCallback 还在执行 MiraiBot::Connect。 有点绕，大概就是自己销毁了自己。(应该不会导致程序崩溃，因为 WebSocketClient::LostConnectionCallback 是在一条 detached 线程(WebSocketClient::RecvLoop所在的线程)里执行的，但是这个线程的 thread 对象肯定是被析构了)

如果执行 MiraiBot::Reconnect，应该不会有问题，因为它只是重新验证，并执行 WebSocketClient::Connect（前面提到在 WebSocketClient::LostConnectionCallback 里调用 WebSocketClient::Connect 是安全的）。

当初这么搞，是我不想创建那么多线程，因为有了多线程就要处理更多的细节😢。创建新线程执行 LostConnectionCallback 可能是最容易的方法？但是我不知道会不会引入新的问题（如果有人知道，可以直接告诉我吗，省得我去查资料了，手动滑稽）。

现在这些代码的逻辑很绕，但是我多线程编程经验极少，还不知道该怎么处理这些问题，可能需要再学习一下才能搞定它。

[Numendacil]

好的，谢谢大佬回复。我自己这块也不是很熟😂得再多看看学习学习了。

（另外您的WebsocketClient库我觉得写的挺好的，轻量级Client侧应用完全够了，之前试图用websocketpp库发现完全搞不懂（什

[Numendacil]

好像找到了问题所在：Mirai Console在执行exit后很短一段时间内仍然可以调用wsClient->Connect连接成功，但在执行RecvLoop时又会立马报错回调LostConnectionCallback返回。我因为多加了几个throw catch所以之前负责调用Reconnect的那个LostConnectionCallback同样会因为RecvLoop的问题而试图重新连接，从而导致同时有两个Callback在跑（我以为是之前的RecvLoop没退出导致的😂） 感觉解决办法就是LostConnectionCallback调用Reconnect前先用SleepSeconds等待一段时间直到服务端确定完全关闭了再试图重新连接。另外我在MiraiBot::Connect里的OnLostConnection中把直接执行回掉函数改成了 pmem->threadPool->enqueue([&](){ this->lostConnectionCallback(result);}); 感觉好像只要不在回调函数里调用MiraiBot::Connect销毁旧的pmem应该就不会出事（全代码好像就这里会销毁pimpl对象x）

（好像问了一个XY问题，爬了x