Callback userdata

[yaozijian]

1 回调函数或者hio_t需要上下文
读完成/写完成/关闭回调函数也许应该增加一个上下文参数，以便回调函数可以对不同的hio_t进行不同的处理。或者，允许对 hio_t 设置用户数据，就像对 hloop_t 那样。至少，应该提供接口，获取 hio_t 关联到的 hloop_t ，然后再获取 hloop_t 的用户数据。
现在这样的回调函数，太简单，不方便编程。

2 读写失败时的回调问题
读写失败了，就不会调用读写完成回调函数，而是调用关闭回调函数。这太简单了，如果我需要在读写完成回调函数中进行资源释放，该怎么办？需要额外编码记住进行中的读写操作，在关闭回调函数中对没有完成的读写操作进行处理（还不知道读写失败的错误码），这增加了复杂性。

建议参考Windows完成端口的设计
(1) 每个 hio_t 可以关联一个上下文(CreateIoCompletionPort函数的第3个参数）
(2) 每个读写操作可以关联一个上下文（OVERLAPPED结构体）
(3) 无论读写是成功，还是出错完成，都要调用完成回调函数。

代码中是有 hoverlapped_s 类型的，能否开放出来，供用户使用？

我刚开始用 libhv，发现有上述问题，也许是对libhv不熟悉，使用方法错了，请指正。

[ithewei]

感谢您的反馈，
1、hio_t、htimer_t、hidle_t都是hevent_t的子类，所以提供了统一的hevent_xxx接口，如hevent_set_userdata就可以绑定上下文，hevent_userdata返回上下文，hevent_loop返回当前loop，可能头文件中没有特别标注，我加点注释
2、同一个loop下的读用的同一个默认readbuf，写内部会维护一个write_queue，不需要自己分配释放buffer，一般场景也不需要关注写完成事件；读回调中加一层流式解析，组成完整的message再处理，不规定解析协议使用何种buffer更灵活，可参考http模块的流式解析。此外，hio_fd可返回文件描述符，hio_error可返回导致close的错误码。

最后，再次感谢您的反馈，帮助libhv更好的完善。

[yaozijian]

上次回复后，在工作中继续尝试使用 libhv ,几天后还是放弃了。

默认配置下，在Windows中，用CMake-GUI 生成 Visual Studio 项目文件后，编译出来的库，底层是使用非阻塞IO(nio）的，而不是使用完成端口(IOCP）的？对于性能要求不是特别高的场合，用非阻塞IO也没什么。然而，NIO的代码，与 IOCP 的代码，最终对外的行为不完全相同？

我的使用方式是比较常见的一种使用场景：读取协议报文的时候，先读取报文头部；根据头部长度字段指示的主体长度，再读取报文主体。为减少内存复制，先分配一块较大的内存，用于容纳整个报文。在读取完头部的回调函数中，使用 hio_set_readbuf 来调整读取缓冲区，使用同一块内存，跳过头部占用的部分。然而，未能达到预期的效果。经过阅读代码，觉得可能的原因是：
1 libhv 库中 IOCP 部分的代码，支持在读取完成回调函数中使用 hio_set_readbuf，下次读取会使用新设置的读取缓冲区
2 而 nio 部分的代码，行为是不同的：如果对端发送的整个报文已经到达，则代码会一直读取，调用回调函数，直到缓冲区空。在回调函数中使用 hio_set_readbuf 是无效的：下次调用回调函数时，数据不会到新设置的缓冲区中。可能要到套接字缓冲区中已有的数据处理完成，再处理后续到达的数据时，使用 hio_set_readbuf 设置的新缓冲区才会生效。

鉴于这个问题无法解决，又怕后续遇到其他问题，用了几天 libhv 后，最终放弃，还是使用比较传统的 boost.asio 了。

也许我对源代码的理解不深，上述见解不正确，请指正。

[ithewei]

1、目前windows下编译默认用的EVENT_POLL宏，即WSAPoll，性能也不会差，和reactor模式更搭，EVENT_IOCP之前在高并发长时间运行时偶现崩溃，未查到问题，另外IOCP模块也还未集成SSL/TLS，所以暂时搁浅了；
2、在hread_cb中调用hio_set_readbuf重置问题已修复，见上面commit；

感谢您的使用和反馈，因开源时间还尚短，设计和测试未能面面俱到，给您带来困惑和不便之处请多包涵，但发现问题了一定会及时跟进修复。

[madtrapper]

请问有改善IOCP的计划吗？

[madtrapper]

关于IOCP的问题可以考虑集成 https://github.com/piscisaureus/wepoll