@lesismal

老哥牛 b ，感谢纠正我的一个认知错误。
我想当然的以为 Go 的底层线程模型是一个 event loop ，并在里面完成 io 操作，然后和上层多个 worker 做交互。
刚才了解了一下，确实是 event loop 只处理事件，调用发生在上层。

不过。我依然觉得即使基于性能考虑，在流媒体场景也不是十分必须。

第一，现在一条直播流的带宽随随便便就超过 Mb 了，以后的趋势应该是越来越大。即使是 CDN 应用，受限于带宽，连接也不会太多吧。
真要是单个节点那么大的量，我觉得可以考虑多进程了。

第二，流媒体场景，还有一点和很多短连接场景不同，就是连接间有很多交互，比如数据转发。

我看过一些 IO 框架。
基本实现是支持多个 event loop ，然后连接绑定到一个固定的 event loop 中。
一些性能测试，是在自身 event loop 中 echo 数据，这种场景有两个特点：
1. 没有涉及到跨协程交互，可以无锁。
2. 理论上，一个 event loop 的所有连接可以共用一块读内存，因为不会长久持有。

这种接口型的业务场景可能对比起来比较明显。


我自己工作中也是写 c++的。以前也写过网络库。 ：）

slack 没有使用过。英文不行。。

@markgor

优点：
相对比的话，
srs 是非常非常优秀的流媒体项目，
我觉得不敢说优点，只能说最大的特点或者区别是，lal 是 Go 写的，srs 是 c++写的，
因此，可以利用 Go 的一些良好特性，比如对于用户来说，易于搭建的开发环境，跨平台能力，交叉编译，单文件运行部署等。

延时：
lal 项目中有很多测试 demo ，其中就有延时测试工具。
lal 的延时和第一梯队的 c++项目是持平的。

@lesismal

老哥一看就是高手，以后多多指教哈。

协程数量方面：
流媒体应用的特点是单个连接吞吐量大，受限于带宽，实际连接数不会太多，所以连接对应的协程数量也不会太多。

线程模型方面：
另外一点我不知道理解的对不对啊，现在的 IO 框架，还有一个优点是 IO 线程可以多个，Go 标准库底层只有一个 IO 线程。
但我觉得在流媒体应用场景下暂时也不会成为瓶颈。

所以目前以我有限的认知前提下，考量到引入 IO 框架后，依赖增加，代码风格不 Go style ，以及后续如果扩展第三方协议（比如 QUIC ）库时的兼容性，我暂时不会集成 IO 框架。

如果未来我发现使用 IO 框架可以给 lalserver 带来很大的性能提升，我会考虑集成。

内存管理确实是流媒体应用的一个重点。我一直有考虑并且会持续优化。

再次感谢老哥指教，可以加个微信，有机会多讨论。