CGO signal handling and garbage collection

Getting Help
1

I have a C++ application that using GO API to perform some tasks using cgo. The go code is built into a static library which is linked to the C++ application. While running the application and analyzing on htop, I see multiple threads spawned because of go runtime.

Questions I want to ask: -

  1. Why the go runtime spawns so many go routines when I am using single go routine as mutator thread (confirmed with the pid of the C++ code and Go code).
  2. If I use the GO API at the start of my application, will the GC will be called at the later stage of application when no GO API’s are called. (considering I am not storing any reference to the go code).
  3. If there is a signal while the process is executing, and C++ applications have installed the its own handlers. How does Go handles it.
  4. Is there a way to completely turn off the GO runtime and make it release all the resources acqurired by these idle threads that the go has created.
2

The Go runtime may spawn multiple threads even if you’re using a single goroutine. This is because goroutines are multiplexed onto multiple OS threads managed by the Go runtime, which can lead to the creation of more threads than goroutines. The Go scheduler handles the distribution of goroutine execution across these threads.

3

Is there a way to manipulate the number of threads created by the runtime. Or a way to execute the code in single thread.
I have a use-case of having a single threaded application and don’t want Go’s concurrency. Also it is important to use Go!

4

The Go runtime maintains a pool of goroutines for efficiency. Even if you only call one Go routine from C++, the runtime might spawn additional ones to handle potential future Go calls or background tasks.