搭个 BN 大家一起玩？
https://github.com/pvpgn/pvpgn-server

@tairan2006
gobwas/ws 存在明显缺陷:
https://github.com/gobwas/ws/issues/143
https://github.com/gobwas/ws-examples/issues/18

看作者的意思是不想解决并且 close 了 issue （其实按 gobwas 的思路也确实没办法解决）

刚想贴一段：
https://gist.github.com/lesismal/0e6de663bc22a620c641832e348ecc60

发现与 @Contextualist #4 基本一样

@pushy gobwas/ws 存在明显缺陷，我有在它的 issue 列表里讨论，有兴趣可以翻看下。作者的意思是不想解决并且 close 了 issue （其实按 gobwas 的思路也确实没办法解决）

> 但是 gorilla/websocket 貌似没见太多替代品？

@phithon
https://www.v2ex.com/t/919140#reply3

每当看到这种话题，我都为自己用的是几十块的普通键盘感到羞愧；
每当看到一些 HHKB 同学的垃圾代码，我都替 HHKB 键盘感到耻辱。

RIP

@hzzhzzdogee 代码 append 了下，代码量更少了，也变强了：
1. 增加了 context
2. 去掉了 rollback 回调，因为类似 sql 那种 defer rollback()就可以了
3. 子任务 err 后就不再向上调用父任务了

虽然想不出实际场景哪里需要这样用，但是蛮有趣的

AMD 又骗我 YES ！
再买 AMD 我是狗！

这行业里的老大 SAP 还有各种学习认证呢，ERP 这种系统还是很复杂的

快速发展的事物，"向前兼容"会导致"向后不行"。nodejs 这些年才叫一个快

@piaodazhu
百十来行随便写了个树状的并发流控：
https://gist.github.com/lesismal/6b397b12bb1e328395873a2c35a71af0

这个树状，基本就可以衍生出各种并发依赖的流程的控制了，而且直接结构体树状生命就可以，看上去可能清晰点。
并发度也是先执行最底层依赖、即叶子节点，每个 node 的叶子都执行完后、其中最后执行完的那个叶子协程复用继续执行该 node ，并依次层层向上直到根任务、整个任务树完成。如果想限制协程数量，把直接使用 go 创建协程的部分改成使用协程池就可以了。

只是简单示例，所以没加 context 之类的，而且实际情况中 context 的 timeout cancel 这些也都存在临界问题。
比如 sql ExecContext ，context 可能超时返回 error 了，但其实数据库已经收到了指令并且执行成功、只是返回的比 timeout 时间久了一点点。所以 context 这些并不能保证幂等性。
如果多个并发流的任务其中一个或者多个发生错误并已经触发了 rollback ，go 里也没法去用 context 或者其他方式强制其他协程中止流程，只能是执行到某一步时去判断了 context Done 或者状态才能提前中止，所以请不要在意失败示范中 rollback 后还打印了 4 的日志。

单进程内的事务也好，那些所谓的分布式事务也好，数据要求强一致的场景，基本都是要靠数据层的数据状态来做幂等性判定。
分布式事务的那些流程设计、方案设计，也几乎（或者更自信点，把这几乎这两个字去掉）没有能够百分百确保完全依靠代码实现执行成功或者回滚，往往需要人工流程手动操作。

> Tasks will run concurrently, but taskB will not start until taskA completes, and taskC will not start until both taskA and taskB complete. But if taskC failed (return err!=nil), ExampleUndo("BindArg-B") will be executed.

这。。如果我没看错的话，这串行执行就可以了吧：
A()
B()
if err := C(); err != nil {
Undo()
}

这弄成并发任务管理器去做，是不是把本来简单的问题复杂化了。。

因为没有一个真正够好。

@777777 #6 你不是一个人！喜欢 if err 的人多着呢，只是我都懒得喷那些喷 if err 的人罢了

> 不开新 goroutine 好点, 反正 http 包里面很多东西 gc 不了.

是。标准库让人又爱又恨的

> copy 比 append 更快些

恩。
前提是得比较明确 size cap 这些，很多地方是 buffer size 可能不够，即使 copy 也是得先 append 扩容。
预先知道 size 并且分配了足够 size 的 buffer ，我也是 copy:
https://github.com/lesismal/nbio/blob/master/nbhttp/websocket/conn.go#L263