no_one

Sorry, there is no plan to add it yet.

sorry， 目前还没有感觉到C++17重构的明确收益。

第一个问题的原因是：内核的发送buf没办法把这么多的数据全部放进去，所以cppnet会自己做个cache chains缓存一下，这个cache chains是用双向链表管理的，而链表的节点又是通过智能指针管理的，所以当很长的节点被释放的时候，会在析构函数中形成很长的调用堆栈。如果有大数据量的发送需求，可以修改下cppnet/cppnet_config.h中的__mem_block_size参数，修改下cache chains单个节点的缓存大小，减少链表的长度。 从根源上讲，这是个cppnet write的设计问题，当发送大量数据的时候，是否需要全部canch到内部的缓存中，现在是一股脑的都放进去了。 第二个问题是windows下的行为和linux不一样，我之前没有覆盖到测试，欢迎提交和mr。 感谢提交的issue!!

我也查了一下，10035是WAEWOULDBLOCK，表示写入缓存已满，但这里很奇怪，如果写入区满的话，返回值的应该没有写入数据(ret._return_value为0)，现在是即有写入数据，errno又为WAEWOULDBLOCK，难道是本次写入导致的内核buf写满？ 从原理上讲，errno == EINPROCESS 和 errno == WAEWOULDBLOCK(10035)都应该从本次写入循环中 break，等待下一次写入，不应该在尝试调用writev接口了。

` 我看了下日志，确实ret._return_value为0 ` 那应该把WAEWOULDBLOCK 和 WAEWOULDBLOCK的判断放到 else下边的 if 中，和 EWOULDBLOCK 之类的判断放在一起就可以了。上边儿的判断 ret._return_value >= 0 应该修改为 ret._return_value > 0。 ` 出现这种情况理论上不应该break。感觉设置一个重试次数，或者相比上次，对端socket是否还在持续接收数据。 ` No, No, No. 异步的交互，当内核的发送缓存满了，就应该立马停止发送，然后向epoll/IOCP注册写事件，等待通知，通知回来再接着发送，发送不完再等通知。不应该再重试任何一次。 其次，发送接收不匹配是很正常的现象，可能是对端接收满，也可能是网络拥塞发送慢，这在发送端是感知不到为什么的，应用层唯一能感觉到的就是write接口写不完要发送的数据了。 cppnet应该添加个内存限制，触发限制就在接口处返回false, 不然cache chains会很大。

 这里的逻辑会去注册写事件，然后在内核发送缓存有位置的时候  这里会回调回来继续发送。 第一个图里，如果没有判断EINPROGRESS之类的标识，进不了第一个if，就会走到之后的关闭流程中去。

验证通过的话，可以帮忙提个mr，一起完善 D:)