NOTE: 关于请求顺序处理 about link

[goghcrow]

handler是自己实现的,应该注意一下,又或者ReadPacket()阻塞,go handler()

[bg5sbk]

是的，如@goghcrow所说，Session.ReadLoop()其实是一个简便用法，满足大部分顺序处理请求的情况，如果需要并行处理请求，应该调用Session.Read()自己封装handle过程。

通常我们不会允许单个客户端同时有多个请求被处理，一方面是有安全风险，单个客户端可以发起大量请求让服务器陷入繁忙，另外一方面服务端并行处理单个连接的多个请求也需要比较复杂的程序逻辑来防止出现死锁或脏数据读写等并行计算常见的BUG。

但是凡事没有绝对性，所以才会做了Session.ReadLoop()之后又提供了Session.Read()。

[bg5sbk]

不过目前Session.Read()的设计有问题，因为内部为了优化性能用了重用的buffer，一个Session被多个goroutine调用时，需要加锁。

加锁不是主要问题，因为要读取完整的包，必然同一次读取只能由一个goroutine完成，所以读单个包的过程加锁是合理的。

不合理的是内部的重用buffer被直接返回，如果外部在复制数据之前就把锁释放了，那么就有可能出现下一个读操作污染buffer的情况。

所以我晚一些会提交一个修改，去掉Session.Read()的buffer重用，但是Session.ReadLoop()我还是想保留buffer重用。

[bg5sbk]

已经提交：commit 0689daf6f1

[nodephp]

Session.ReadLoop() buffer 现在没有重用了？

[nodephp]

设计上应该只有一个 goroutine 负责读 ，一个goroutine负责写

[bg5sbk]

@nodephp 最初的设计是内部一读一写，但是觉得这样有局限性，如果只是简单的顺序连接和请求处理的场景，多开一个goroutine是浪费，所以把读的goroutine创建交给使用者，需要的人可以自己go session.ReadLoop()。