C code and goroutine scheduling

When I invoke a C code from a goroutine, does it affect scheduling of other goroutines in any way? I know that if I call a NIF in Erlang, it blocks the other (Erlang) processes, until the function returns. Is this the case in Golang? Does C code block the goroutines scheduler?

Calling a C function from Go code does not prevent other goroutines from running.

It does have an effect on the scheduler. A goroutine running a C function does not necessarily count against the GOMAXPROCS limit. It will start out counting against GOMAXPROCS, but if the C function has blocked for more than 20us at the time the sysmon background goroutine runs, then the scheduler will be permitted to start another goroutine if there is one ready to run. These details depend on the specific Go version and are subject to change.

This is a very good question for which I did not find any official statement on the fly except in the code. I would be glad for any hint to official documentation.

The answer is no, cgo calls do not block the scheduler.

For the following it's good to know that internally Go uses G for goroutines, M for machines (threads) and P for proccessor. Goroutines are run on processors that run on machines.

Calling a C function from G works as follows according to the code documentation:

// To call into the C function f from Go, the cgo-generated code calls
// runtime.cgocall(_cgo_Cfunc_f, frame), where _cgo_Cfunc_f is a
// gcc-compiled function written by cgo.
//
// runtime.cgocall (below) locks g to m, calls entersyscall
// so as not to block other goroutines or the garbage collector,
// and then calls runtime.asmcgocall(_cgo_Cfunc_f, frame).
//
// runtime.asmcgocall (in asm_$GOARCH.s) switches to the m->g0 stack
// (assumed to be an operating system-allocated stack, so safe to run
// gcc-compiled code on) and calls _cgo_Cfunc_f(frame).
//
// _cgo_Cfunc_f invokes the actual C function f with arguments
// taken from the frame structure, records the results in the frame,
// and returns to runtime.asmcgocall.
//
// After it regains control, runtime.asmcgocall switches back to the
// original g (m->curg)'s stack and returns to runtime.cgocall.
//
// After it regains control, runtime.cgocall calls exitsyscall, which blocks
// until this m can run Go code without violating the $GOMAXPROCS limit,
// and then unlocks g from m.

entersyscall essentially tells the runtime that this goroutine is now under 'external' control, just like in the situation when we do syscalls to the kernel. Another probably useful bit is that locking g to m (locking the cgo calling goroutine to the OS thread) enables the runtime to allocate a new OS thread (theoretically exceeding GOMAXPROCS).