package main
/*
#include <stdio.h>
void myhello(int i) {
printf("Hello C: %d\n", i)
}
*/
import "C"
import "fmt"
func main() {
C.myhello(C.int(12))
fmt.Println("Hello Go")
}
需要注意的是C代码必须放在注释里面
import "C"语句和前面的C代码之间不能有空行
运行结果
$ go build main.go &&./main
Hello C: 12
Hello Go
分开c代码到单独文件
嵌在一起代码结构不是很好看，很多人包括我，还是喜欢把两个分开，放在不同的文件里面，显得干净，go源文件里面是go的源代码，c源文件里面是c的源代码。
$ ls
hello.c hello.h main.go
$ cat hello.h
void hello(int)
$ cat hello.c
#include <stdio.h>
void hello(int i) {
printf("Hello C: %d\n", i)
}
$ cat main.go
package main
// #include "hello.h"
import "C"
import "fmt"
func main() {
C.hello(C.int(12))
fmt.Println("Hello Go")
}
编译运行
$ go build &&./main
Hello C: 12
Hello Go
编译成库文件
如果c文件比较多，最好还是能够编译成一个独立的库文件，然后go来调用库。
$ find mylib main
mylib
mylib/hello.h
mylib/hello.c
main
main/main.go
编译库文件
$ cd mylib
# gcc -fPIC -shared -o libhello.so hello.c
编译go程序
$ cd main
$ cat main.go
package main
// #cgo CFLAGS: -I../mylib
// #cgo LDFLAGS: -L../mylib -lhello
// #include "hello.h"
import "C"
import "fmt"
func main() {
C.hello(C.int(12))
fmt.Println("Hello Go")
}
$ go build main.go
运行
$ export LD_LIBRARY_PATH=../mylib
$ ./main
Hello C: 12
Hello Go
在我们的例子中，库文件是编译成动态库的，main程序链接的时候也是采用的动态库
$ ldd main
linux-vdso.so.1 => (0x00007fffc7968000)
libhello.so =>../mylib/libhello.so (0x00007f513684c000)
libpthread.so.0 =>/lib64/libpthread.so.0 (0x00007f5136614000)
libc.so.6 =>/lib64/libc.so.6 (0x00007f5136253000)
/lib64/ld-linux-x86-64.so.2 (0x000055d819227000)
理论上讲也是可以编译成整个一静态链接的可执行程序，由于我的机器上缺少静态链接的系统库，比如libc.a，所以只能编译成动态链接。
实现指定个核心最大化使用，比如核心总数减一。
必要的库。
要使用的cpu数量，建议不全使用。
建立管道。
声明使用的cpu数。
建立互斥关系，本例中主要为了实现所有线程执行完后再执行后续程序。
创建cpu数减1个线程
后面每个任务结束时要done一个wg，这里根据具体情况加，是循环就在每个循环里加，保证后面能全部done即可
没有缓冲的、阻塞式的往管道传递字符串。
Wait是等所有线程都执行完，即增加的数字被全done掉。
关闭管道。
假设已有的函数是ReadLogs，在它的基础上加个Wg加函数名的新函数，我觉得这种方式不改变原有的，比较舒服。
大意是：循环从管道读取字符串，读不到了就跳出循环。
每个ReadLogs()之后加一个wg.Done()，相当于计数减一。
ReadLogs()就是要执行的任务，不再解释。
就是开指定个线程。
管道阻塞传值。
wg同步。
WgReadLogs循环接收。
最近三年，在工作中使用go开发了不少服务。深感go的便捷，以及它的runtime的复杂。我觉得需要定期的进行总结，因此决定写这篇文章，也许更准确的，应该叫笔记。
最近终于解决了一个和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的运行时是一个庞大的怪物。因此，抱着能了解一点是一点的心态，不断的完善这篇笔记。
