On Thu, Nov 1, 2018 at 2:58 PM, Michael MacInnis <michael.p.macin...@gmail.com> wrote: > > On Thursday, November 1, 2018 at 12:20:39 PM UTC-4, Ian Lance Taylor wrote: >> >> >> Every blocking cgo call requires a thread. Also every Go program has >> a supporting thread that monitors the programs. If you see only 4 >> threads for that program then I think we're doing pretty well. >> >> Ian > > > I wasn't implying that seeing 4 threads with GOMAXPROCS=1 was good or bad. > Just that it was surprising. > > Running that program with GOMAXPROCS=1 I still find 4 threads surprising. It > sounds like I should see 3 threads: the monitor thread, the thread for the > main goroutine and one more for the blocking Cgo call. Do 2 threads get > created for the Cgo call? > > If I run the following program, > > package main > > func main() { > for { > } > } > > with GOMAXPROCS=1 I see 3 threads. Which is also one more than I was > expecting. > > Again, not implying that this is good or bad. I would just like to know if > there is some way to predict the number of threads a Go program will create.
I encourage you to run the program under the debugger with a breakpoint on pthread_create to see where each thread is created. Offhand I don't know why you are seeing what you are seeing, but I don't think the explanation will be very interesting. Go is designed to work well with programs with lots of goroutines. It's not designed to minimize the number of threads for small programs. In general, there is no simple way to predict the exact number of threads that a Go program will create. You can only predict trends. Ian -- 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.