I get it. Thanks a lot 在 2017年8月4日星期五 UTC+8下午8:52:36，Konstantin Khomoutov写道： > > 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.
