宅の士

遇到同样的链接错误，排查老半天才发现问题出在hv的json版本与自己的json是同一个开源库导致ifndef宏约束形成声明与实现包含的json版本不同产生链接错误。。最后把自己fork的hv更新json解决了顺便提了pr

https://github.com/House-Men/libhv/commit/144a64b1c397da93cae318e6f96974511e17a4a7 参考这个修改项 只需改nio.c 三个地方就可以支持0字节了

你这问题和我之前遇到的有些类似，[我当时提的issue](https://github.com/ithewei/libhv/issues/535) 可惜作者说 可以在main_ctx_init后自行再重新设置conf/pid/log等路径(不过我确实没看出怎么在不调整main_ctx_init逻辑的情况仅更改自定义目录) [并且属于定制化改造需求只能自己维护fork。[最终我的fork版改造如下](https://github.com/House-Men/libhv)

> There is another issue, in lines 87 to 90 of the file base/main. c, the following log file path don't use the variable logdir 你说的应该是这个logdir，目的就只是为了尝试创建个目录，只不过后面又用snprintf和logdir同样的方式+文件名保存到g_main_ctx.logfile，也并非没有用到logdir ```c++ char logdir[MAX_PATH] =...

> 建议分成多个PR吧，有些可能为了兼容性不可被接受 hv.lib -> libhv.lib，因为很多项目直接链接的hv.lib，现在已经不方便改了，_static后缀同理 添加win32共享库lib前缀并不会改变hv.lib，只会改变hv.dll，不会影响链接，如果这样也不行可以把这个和Linux去除_static这两项改动编辑去除，我是设置了Allowing edits by maintainers。没必要把每个小改动单独拆成多个PR把，还是说一个改动一个PR有什么其他优势必须这样做吗？

 https://github.com/ithewei/libhv/commit/6900f97a50d8cc64ea8504ff2e85aa8d2b422dcd 这个提交后的版本可以支持中文

这并不是这一处vsnprintf用法问题，还有其他地方也存在可能因超出bufSize导致崩溃，根本问题在于hlog并不是防御性编码风格主动做了参数检查防止超出bufSize，这样的函数属于契约式编码，要求打印log时调用者必须确保绝不超过bufSize，默认bufSize=16k，可通过logger_set_max_bufsize调整。

> 难道说多线程使用的相同的一个fd? 如果将监听端口重用打开,所有线程自己创建一个fd,监听可读事件,操作系统就会帮你尽可能平均分配连接,不会出现惊群现象. > > SO_REUSEPORT SO_REUSEPORT 是惊群最好的解决方法，Nginx 在 1.9.1 中加入了这个选项，每个 worker 进程都有自己的 socket，这些 socket 都 bind 同一个端口。当新请求到来时，内核根据四元组信息进行负载均衡，非常高效 这个方法局限性太大了，Windows完全不支持，Linux也只有多进程模式支持，多线程不支持。

> 根据 [RFC 3986](https://tools.ietf.org/html/rfc3986#section-3.4) 标准定义，URI 的通用语法结构为： > > scheme:[//authority]path[?query][#fragment] > > （方括号表示可选，但顺序不可调换） 标准格式顺序确实是这样，但是#字符的出现代表后面可以是任意剩余字符，其中就可以出现?，而且代码 http/HttpMessage.cpp 中对 HttpRequest::Path() 的处理也是有?与#做了优先级处理的，经过主流浏览器地址栏与开发者工具观察请求报文也是可以证实确实存在优先级处理，#如果比?优先出现那么后面都属于fragment而不会识别成path=/xxx/xxx.htm#xxx，query=xxxx，fragment=空

原因是执行启动的时候 loop_->runInLoop(std::bind(&UdpClientEventLoopTmpl::startRecv, this)); 这个是投递启动事件到loop线程异步触发启动，而startRecv还没来得及执行你的UdpClient对象就析构了，导致后续startRecv启动后使用的this指针父类Channel相关内存数据全部无效从而崩溃。 而不使用外部loop时不存在此现象是因为is_loop_owner=true的内部线程stop时会执行终止线程。 要解决这个问题就必须作者想个好办法优化stop逻辑，我发现许多cpp封装对象涉及异步事件执行的地方都可能因this对象析构从而产生崩溃潜在问题，临时解决方案就是调用start之后检测hio的事件是否不等于0来判断异步触发启动完成可以执行后续停止或析构，我在你的代码示例基础增加 while (hio_events(client1.channel->io()) == 0) std::this_thread::yield(); 即可避免崩溃。 @ithewei @hello-Li-sir