@liaohongxing

与其他标准库为基础的框架结合，是替换了标准库 net.Conn 这些，因为 nbio 是异步的了，不能再像标准库那样子一个连接一个协程了，要用 nbio/nbhtt/websocket ，代码在这里：
github.com/lesismal/nbio-examples/blob/master/http_with_other_frameworks/echo_server/echo_server.go

gin 的也在这个仓库里，其他标准库为基础的，也能类似方式

@cdxjcl123 其实脾气一点都不好，只是线上也拿他没办法，要是线下我就直接对他狮吼功了。。


@janxin "race issues"应该是指 golang race condition, 一些变量未加锁并发访问时，开启这个选项会有 race 相关的 warning ，就是并发访问竞争、一致性这种问题。std 方案那种无状态的服务通常很少涉及这种。一些场景能够满足并发访问安全，则也是没必要加锁的，nbio 里的应该都是 ok 的。race 只是帮助检查代码可能存在的问题，确认没有问题就好了


@iyaozhen 干净的代码，demo 比文档看着更直观。项目历史包袱确实烦躁，即使你给他 java 他也可能有另一种吐槽 囧


@zooeymango 你这种就是社区之光了，哈哈哈，都这样子的话，估计 linus 也就不会火爆脾气了


@lookStupiToForce 对对对，巨婴！太可怕了。老外确实是大神多，但是更多人也是不钻研很深，都是专注自己业务领域、经验多了升职加薪就行，因为人家没有 35 淘汰、可以干到退休，人家的社保也时真能保障未来，所以都是命吧。。。


@fenglangjuxu 感谢兄弟支持！


@chengkai1853 过奖了，我是 issue 少所以这么耐心，中文的 issue 还好，英文的我这回复一条也花好一阵功夫，要是真多了，估计也扛不住。。。


@XiLingHost 项目情况不一样，issue 数量不多，也还好，要是哪天有机会多起来了，模板 lable 各种也都搞起来，看不过来就也不能那么认真回复了。。

@twing37
#71 文档确实难写，异步库并发、时序相关的细节太多了，但是提供给应用层的接口仍然是同步方案，异步不容易描述清楚、写多了反倒会让写同步逻辑的同学迷惑，所以是写了很多 examples 为主，囧
#72 对，最开始发关于 nbio 的帖子的时候，记得有个 'byte0' 大神给我一顿教学，哈哈哈，我一顿回复后都没鸟我。后来在其他帖子里见到他有点黑 go ，at 他他也不鸟我，估计把我 block 了吧 囧

@YaakovZiv 还遇到过更奇葩的，去某个中小公司面试，面试官比较稚嫩，问一堆他们项目里遇到的实际问题，我就把解决方案都给面试官教会了，然后面试结束给个很低的薪资问我来不来，只能一笑而过，且当手有余香吧

@proxytoworld
分两个大阶段

第一阶段是只支持 poller ，实际上不复杂，具体花费的时间不记得了，核心部分主要是 io 、其实只要几天，剩下的就是换不同的姿势折腾和测试，比如 timer 是用时间轮还是最小堆，内存简单优化、接口易用性扩展性之类的偶尔完善下，实际花费的时间不算太多

第二阶段是对 tls/http1.x/websocket 的异步支持，也支持 client-side ，支持同一个 engine 里跑 client/server/tls/non-tls 。这个去年也消耗了几轮，实现 http1.x/websocket 的异步流解析器，tls 太复杂、图省事直接魔改标准库实现了异步解析器支持。另外花费的最大头时间是内存池优化，把 4-7 层，从 tcp 到 tls 到 http/websocket 各层的内存池打通。因为全是异步（可能 half-packet ），涉及很多 half-packet buffer cache ，打通这几层细节比较多，测试也麻烦，花费的时间比较多。也没有用其他那些基于同步方案的 2^N size 内存池，因为同步方案，每个 conn 一个协程处理读，循环读，buffer size 可控并且容易复用，不涉及复杂的异步 half-packet cache 逻辑，所需的 buffer size 也容易设定，2^N 逻辑也比较容易，而异步方案里，不确定性很多，比如对象、buffer 的跨协程生命周期管理，half-packet 相关的涉及很多 mem move/copy ，用 2^N size 实测反倒比标准库方案内存占用更多、十分拉垮。所以这些细节花费的时间较多，到主体成型，加起来花了估计有三个月以上吧，加上各种 example 之类，应该是有三个月以上了，没细算过

@tywtyw2002
@ericwoflskin

恩恩，以后遇到不合理的问题就不回了，既浪费感情又浪费自己时间。

以前看到一些关注度高的项目作者不回复或者很久回复，因为作者们确实事情多、issue 也多，忙不过来。

但是自己项目关注度不高，闲余时间就尽量回复了，而且多回复一些，以后有其他人遇到类似问题直接搜出来就不用重复回复了。只是没想到这次遇到的这位会这样子 :joy:


@paulw54jrn 感谢支持！

@mirone 没事，平常心，"不愠不郁"是下一个修炼目标:joy:

@abbottcn
“然后被拉黑了”这操作有点太过了，防着别人图他啥似的

@ohmyself 以后再遇到这种，我就尽量不回

@Herong 感觉他送你游戏是为了结个善缘，说不定以后你能帮他推广更多人，结果啪啪被拒:joy:

@skiy 对，所以我也只是“估计”，老外不是也遇到过逗逼，这玩意跟地域、种族发达程度受教育程度有关系，可能比例有高有低，但是对于个体事件、没有直接关系，看运气，碰到了是自己倒霉:joy:

@wzxlovesy 他这样做之前，不知道他是这种。他这样子之后，他自己都说了不再来了，哈哈哈，所以算了，万一哪天他成长了呢

@mdgwmt0 看运气吧，正常人还是多数

@0o0O0o0O0o
eranyanay/1m-go-websockets 这个库，去年有人在我 arpc 的仓库里提到过，建议我参考它一下，所以我去简单扫了几眼他的源码，目测是有问题的并且写了个 demo 很容易就复现了，在这里和后面的部分： https://github.com/lesismal/arpc/issues/2#issuecomment-746694287

他们只依赖 easygo 实现了事件触发读，却没有实现异步流解析、半包处理、并且对于单个 conn 仍然是阻塞读完整包，所以当一个 conn 收到 half-packet 的时候，这个 conn 的 Read 就阻塞了，而这个 conn 阻塞，它所在的 goroutine （可能是 poller 协程或者数量有限的协程池）就阻塞了，进而让其他 conn 等待。我之前在这个仓库里提了这个 issue 但是才发现作者竟然把 issue 给禁了？所以看不到了。我也到他们最终使用的 gobwas/ws 里提了 issue 和复现代码，并且有其他人也给他提过 issue 因为遇到过我说的问题，gobwas/ws 的作者更逗，不想解决问题，反而直接 close issue 囧。

eranyanay/1m-go-websockets 、gobwas/ws 这些，都不应该被部署到生产环境，否则慢连接攻击下，甚至不需要攻击，公网有时候就是不够稳定的，他们服务就延迟感人了。所以其实这些库也解决不了那孩子的问题，其他一些异步网络库 evio gev gnet 都还没有支持 tls 、http ，只有 gev 支持了简单的 websocket 但也不支持 tls http 。

go 框架里能搞定 1000k 的，暂时全网就我这一份了。。。:joy:

奇怪，at 多几位就提示需要注册满 1000 天，以前好像不这样子

@PerFectTime
我也是被这句噎笑了，就差我跪着把代码提交到它项目了　囧

一开始提问也还好，但是怕遇到这种豪不思考并且还得寸进尺的，我中间已经比较委婉说了让他自己搜一些基础知识否则我英语回答不到位，结果人家直接给我"no worry..."告诉我不用为自己英语担心、让我放心回答，然后继续弱智问题，所以我才会直说让他自己认真读代码和思考一下，然后人家就干翻我了 :joy:

提示“发布这个内容需要你已经注册满 1000 天”，不知道是不是因为 at 各位进行回复导致的，或者内容太长了？

这次这个我看他 star 的仓库里有个是中文的，估计是国人吧

之前还在一个 slack go 频道看到有个人提问某个 websocket 库的一个用法，说肯付费$50 ，倒不是为了钱，因为没用过那个 websocket 库所以好奇看了眼随便就回答他了，也没跟他要钱，然后提问的那个人直接把他发的内容删掉了...
当时就感触，歪果仁也有不少逗逼啊