On Fri, Aug 04, 2017 at 03:45:49AM -0700, bysui hou wrote: > I'm going to use CGO to call c++ in my project and do some performance > tests. So I do research on cgo, and find that calling a C function from Go > code won't block other goroutines from running. I view the cgocall code > (runtime/cgocall.go, is there any official doc?), it seems that calling a C > function from Go code in cgo would lock g to m and call entersyscall (dose > it means new a thread for running ?). If in go code I make lots of C > function calling, will the program new a thread for each calling?
It's sort of backwards: when a goroutine makes a cgo call it gets locked to the thread it currently runs on until the call returns -- just like a syscall, yes. This does not prevent other goroutines from running concurrently, and the Go runtime is free to spawn another OS thread to max them quantity out up to runtime.GOMAXPROCS because that knob control the number of goroutines running "normally" -- that is, crunching CPU and not sleeping in a syscall or a cgo call. So yes, making lots of cgo calls in parallel might create lots of OS threads. So if you think this is an issue, plan on having one or more "worker" goroutines which receive "tasks" to perform via cgo calls and communicate their results back. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
