@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

> 现在改成用户态拼接 buffer 的方式了, bytes.Buffer 没有 Discard 方法, 压缩那块写得有点丑
> 忽然发现 next 就相当于 Discard :)

@Nazz 主要是你 write frame 的场景，就一 head+body 拼接，太简单了，pool+append 足矣

OP 打工人之光

> 但毕竟不是 c free ，不能立即释放

#4 更正，c free 也不一定是立即归还的、而且多数时候不是立即归还，要看分配器实际情况了

> 单就 upgrade 这个 request 而言，可能上下文的代价比新 go 更大一点

#15 更正，单就 upgrade 这个 request 而言，可能相比于上下文的代价、新 go 代价更大一点

@lysS 跟是不是浏览器应该没关系，而是 ws 协议就是这么规定的，go 的 client 也是要发这个握手的 request 的。

@Nazz 得实测看看，正常情况狂不应该有这个问题。差异不大可能是测试稳定性的问题可以忽略。如果差异很大，代码发我瞧瞧

> bytes.Buffer 应该比手撸的更快

并不是。首先它一样的是挂载在 conn 上需要持续占用大段 buffer ，其次它源码你看下就知道了，还是那些个 buffer 的操作、只是封装些常用方法方便用户罢了。buffer 操作这种事情并没有什么性能提升的秘诀，就是谁的逻辑代码消耗更少、拷贝更少之类的

@Nazz #19 就是因为这些各种原因，很多地方我手撸 buffer ，好累:joy: 。。。

@Nazz #19 我又测了下 bufio.Writer ，跟 buffer append 性能差不多，但 bufio.Writer 是在线连接长期占用这个，buffer append 的方式是当前有写才会占用下、可以复用 pool ，而且并发写有 mutex 的、一个 conn 同时最多也就占一个，总数量<= conn num ，而且核心数没那么多、并发多数时候没有那么多协程达到并行，所以实际应该是小于 conn num ，所以 buffer append 可能更好点

我又测了下 net.Buffers vs user buffer append:
https://gist.github.com/lesismal/a40c420511252aa79b054cbd2acc896e

我的机器上还是 user buffer append 性能略好，而且内存更优，你可以自己环境跑下看看不同环境是否有差异

> 能用于浏览器的，你试试.

刚看了下代码，这。。。

我之前说不能用于浏览器是因为你这句 "支持从 tcp conn 直接解析 websocket 协议" ，以为你是和我发的那个类似、直接 tcp 上的数据解析 websocket ，但其实不是，你这个仍然是先解析 http request 然后 upgrade ，只是没用标准库的 http 、而是自己实现了解析 http request 这步。
所以准确说，是使用自实现的 http request 解析进行 ws upgrade 。
但这个解析不够完备、没有非法字符之类的协议规范的判断，我不确定会不会有一些风险。

> 实测 net.Buffer 稍快点，而且能省掉 bufio.Writer 的内存

可能你对比的是 bufio.Writer ，我之前对比的是 buffer append

> net.Buffer 能减少一次拷贝呢, 没想到底层还是会拷贝

这个可以看下代码，跟进去，TCPConn 这种就是调用的 syscall.Writev 了。
内核 c 语言实现的 writev 也看下就知道了

> demo 里面加 go 是因为我想让请求上下文被 gc 掉, 结果还是有副作用

单就 upgrade 这个 request 而言，可能上下文的代价比新 go 更大一点，但实际应该也差不了太多，runtime 复用协程也是挺给力而且不是高频行为，剩下的主要是逃逸

@lesismal #7 我只是肉眼分析，实际差别应该不会特别大。可以实测对比下玩玩看，需要排除掉多次启动基础内存占用可能不同的一些差别、比如多跑几轮

单就主帖内容，TCP 这个可能会误导一些人、以为可以替换了原来的方案了，所以特地来回复一下，顺便又 review 了几眼

还有一点，在 handler 里其实可以不用新开协程的，socket.Listen() 就可以了、不要 go ，这样就复用了 http server 原来的那个协程、避免了一次不必要的协程重建和一些变量逃逸。比如前面说到的 http conn 挂载的读写 buffer ，因为是默认 4k ，1.18 还是哪个版本之后来着、协程栈好像默认是 8k ，所以一般而言，复用了原来的协程，则挂载的这个读 buffer 至少不太涉及跨协程的逃逸，所以应该是能使用原来这个协程的栈空间，除非你要设置得很大 size