最近终于解决了一个和cgo有关的问题。这个问题从发现到解决前后经历了接近4个月，当然，和人手不足也有关系。而对于我个人而言，这个问题其实历时2年！这得从头说起。
在上一家公司的一个项目里，有一个服务做音视频数据的提取，这个服务运行在嵌入式设备TX2上。音视频提取这一关键功能主要利用nvidia基于gstreamer开发的插件，这个插件可以发挥nvidia gpu的硬件解码功能。当时这个服务使用go和c混编的方式，问题的症状是服务运行一段时间后，不输出音视频数据。遗憾的是，由于疫情，项目停止，因此没有机会继续研究这个问题。
时间来到去年底。当前这个项目进行压力测试，发现关键的语音处理服务运行一段时间后，会出现不拉流的情况，因此也没有后续的结果输出。症状和上一个项目非常像。虽然使用的第三方SDK不一样，但同样用了go和c混编的方式。一开始，焦点就放在go的运行时上，觉得可能是go和c相互调用的方式不对。经过合理猜测，并用测试进行验证后，发现问题还是在第三方拉流的SDK上，它们的回调函数必须要快，否则有可能会阻塞它们的回调线程。当然，在go调用c的时候，如果耗时比较长，会对go的运行时造成一些副作用；在c回调go的时候，go的运行时也有可能阻塞c的回调线程。但go的运行时已经比较成熟，因此我觉得它对这个问题的贡献不大。以上采用了假设-验证的方法，主要的原因还是第三方的拉流SDK不开源。在定位问题的过程中，使用了gdb的gcore来生成堆栈；也搭建了灰度环境来进行压力测试，以及完善监控，这些都是解决方法的一部分。
正是这一问题，促使我更多的了解go的运行时。而我看得越多，越觉得go的运行时是一个庞大的怪物。因此，抱着能了解一点是一点的心态，不断的完善这篇笔记。
显卡带Ti并没有缺点，只是在原显卡上做了加强，英伟达的后缀命名规则如下：
GS:普通版或GT的简化版
GE:简化版，略微强于GS显卡GT标准版，比较常见的显卡版本。相对于GS要高个档次，GT没有缩减管线和顶点单元，目前无论是办公还是家用GT版本最为常用。GTS:介于GT和GTX鉴于之间的版本GT的加强版
GTX:(GT eXtreme)代表着最强的版本，极致版。
SE:和LE相似基本是GS的简化版最低端的几个型号LE(Lower Edition 低端版) 和XT基本一样，ATi也用过。
ZT:在XT基础上再次降频以降低价格。
XT:降频版，而在ATi中表示最高端。MX 平价版，大众类。
TI:(Titanium 钛)以前的用法一般就是代表了nVidia的高端版本。今意：高速加强版
TC:(Turbo Cache)可以占用内存的显卡
Ultra:在GF8系列之前代表着最高端，但9系列最高端的命名就改为GTX，超级版 。
GT2:eXtreme 双GPU显卡。
GX2:（GT eXtreme2）指两块显卡以SLI并组的方式整合为一块显卡，不同于SLI的是只有一个接口。
Go:用于移动平台。
Z:双芯加强版
GF：入门级
