cgo threading challenges with multi-threaded C libraries

WHAT THIS TESTS It checks whether you understand how Go's M:N scheduling interacts with C's thread-per-something model when crossing the cgo boundary, and the practical mitigations.

A GOOD ANSWER COVERS Go multiplexes many goroutines onto a smaller set of OS threads, and a goroutine has no fixed thread. C libraries, by contrast, assume ordinary 1:1 OS threads and often rely on thread-local storage, thread affinity, or per-thread state. When Go calls into C via cgo, the call runs on a real OS thread (an M); because the C call may block arbitrarily, the runtime detaches that M's P so other goroutines keep running, and the C code is opaque to the Go scheduler.

CHALLENGES Thread-local storage in the C library is unreliable from Go because the same goroutine may resume on a different OS thread between calls, so state stored against thread identity can be lost or seen by the wrong work. Callbacks from C back into Go are expensive and require the runtime to set up a goroutine context, and care is needed around the stack. Signal handling, thread affinity (for example GPU or GUI libraries that demand a specific thread), and the per-call overhead of crossing the boundary all add friction.

SOLUTIONS Use runtime.LockOSThread (with UnlockOSThread) to pin a goroutine to a dedicated OS thread when the C API needs thread affinity or TLS continuity, such as OpenGL or some GUI toolkits. Minimize the number of cgo crossings by batching work into fewer, larger calls. Funnel all interaction with the library through a single dedicated worker goroutine that is locked to its thread, serializing access and giving the C side a stable thread. Avoid frequent Go-to-C-to-Go callbacks.

COMMON WRONG ANSWERS Assuming each goroutine is its own C thread. Thinking cgo calls are free. Ignoring thread-local-storage and affinity issues.

LIKELY FOLLOW-UPS Why does cgo have per-call overhead? When exactly is LockOSThread required (e.g. OpenGL contexts)? How do C threads that call into Go get registered with the runtime?

ONE CONCRETE EXAMPLE Driving an OpenGL context, which must be made current on and used from one specific OS thread, from Go: you spawn a dedicated goroutine, call runtime.LockOSThread at its start so it never migrates, make all GL and related C calls from that goroutine, and have the rest of the program communicate with it over channels. This satisfies the library's 1:1 thread-affinity expectation despite Go's M:N scheduler.