The Go runtime cannot perceive the internal execution logic of C functions, and the memory management on the Go side is isolated from that on the C side. Therefore, calling in_c_foo via CGO does not have any special impact on the Go runtime. CGO is merely an FFI implementation, with both sides sharing the same process address space. When writing C code, you can think of the Go runtime as an independent CSP thread pool running within the same process—while sharing process resources, their logic remains isolated. However, you still need to be aware of three risks:
If the C function spawns new threads, the Go scheduler will not be aware of them, which may lead to resource contention or leaks.
While a C function is executing, the current M (OS thread) becomes locked, preventing it from running other Goroutines.
When passing pointers to the Go heap, if the C function uses such a pointer asynchronously, it might result in a dangling pointer due to the shrinkage of the Go heap.
Therefore, it is crucial to rigorously scrutinize the passing and usage of pointer objects to avoid situations where both C and Go concurrently reference the same pointer object in different threads.