Master CGO: Deep Dive into Go‑C Interoperability, Performance & Interview Secrets

What Is CGO?

CGO is the official bridge that lets Go code call C functions and exchange data, enabling integration with system‑level C libraries, mature C/C++ SDKs, performance‑critical modules, and low‑level resources such as drivers or kernel interfaces.

Why Is CGO Slow?

Each CGO call incurs runtime coordination before entering and after returning from C code. The main overheads are:

Switching from the Go stack to the C stack

Triggering a garbage‑collector safepoint check

Marking the current thread (M) as "in syscall"

Detaching the current processor (P) from the thread so other goroutines can run

Re‑acquiring a P when the C function returns

Cross‑language type conversion for strings, slices, structs, etc.

The cost comes from the cross‑language switch and scheduler coordination, not from the C code itself.

Does CGO Block the Go Scheduler?

When a goroutine invokes a CGO function, the underlying thread (M) is blocked, but the scheduler continues to run other goroutines because the processor (P) is released to other Ms. The flow is:

Goroutine calls C

M enters "in syscall" state

Scheduler detaches P from this M

Other goroutines run on the detached P

When C returns, M tries to reacquire a P

Thus CGO behaves like a syscall: it yields the processor without halting the whole runtime.

Pointer Rules Between Go and C

Go → C: Go pointers (including those inside maps, slices, strings, and structs) must not be passed to C unless a special exception applies. The garbage collector must track Go heap objects precisely, and C has no knowledge of Go’s pointer semantics; additionally, Go objects may move, leaving C‑held pointers dangling.

C → Go: Memory allocated by C is not managed by Go’s GC and must be freed explicitly on the C side (e.g., with free).

Classic CGO Example

package main

/*
#include <stdio.h>

void hello() {
    printf("Hello from C
");
}
*/
import "C"

func main() {
    C.hello()
}

Key observations:

CGO generates intermediate .c and .h files.

The compilation step invokes gcc (or the configured C compiler).

Each call to a C function triggers the cross‑language boundary switch described above.

Three Memory‑Management Rules for CGO

Rule 1: Do not pass Go pointers to C unless an explicit exception is documented.

Rule 2: Free any memory allocated by C using the appropriate C deallocation function (e.g., free); Go’s GC does not manage it.

Rule 3: Convert Go values to C types explicitly, e.g., C.int(x) or C.double(f).

Performance Optimization Tips

Minimize the number of CGO calls; batch work in a single C function when possible.

Reduce cross‑language data conversion, especially for large strings or slices.

Consider pure Go implementations or direct syscalls if they can replace the C dependency.

General rule: avoid CGO unless the functionality cannot be achieved otherwise.

When to Use CGO

Integrating existing C/C++ system libraries.

Image, audio, or video processing that relies on native codecs.

Cryptographic libraries such as OpenSSL.

High‑performance networking stacks (e.g., DPDK).

When Not to Use CGO

High‑frequency RPC or hot‑path code that demands maximum concurrency.

Cross‑platform services where binary portability is critical.

Statically linked builds where external C libraries complicate the build process.

Situations where the C library’s stability or licensing is uncertain.

High‑Frequency Interview Questions

Why is CGO slow? Because crossing the language boundary triggers stack switching, GC safepoint checks, and scheduler yielding.

Does CGO block the Go scheduler? No. The thread (M) is blocked, but the processor (P) is released, allowing other goroutines to run.

Why can’t a Go pointer be passed to C? The GC cannot track it, the object may move, and C could corrupt memory.

Who frees memory allocated by C? The C side must free it; Go’s GC does not.

When should CGO be avoided? In high‑concurrency, cross‑platform, or performance‑critical hot paths where the overhead outweighs the benefit.