Thank you for the clarification Ian. So to sum up: the reason for the number of threads being more than GOMAXPROCS, is that a thread has been in a syscall or blocking state, perhaps due to opening a file or some I/O operation, and the runtime has spawned a new OS-thread to maintain GOMAXPROCS-number of executing threads. Therefore, the number of threads above GOMAXPROCS is a product of how much simultaneous blocking/cgo/syscalls are performed.
tirsdag 23. august 2016 15.21.07 UTC+2 skrev Ian Lance Taylor følgende: > > On Tue, Aug 23, 2016 at 1:54 AM, Lars Kulseng <larsk...@gmail.com > <javascript:>> wrote: > > > > I have tried to find some onformation about how OS-threads are created, > and > > what their roles are. I know that this doesn't really matter in a lot of > > cases since goroutines are multiplexed on top of OS-threads and they are > > usually created at startup of the program, but I'm just trying to > understand > > what is happening. > > > > Can someone help me understand this? So far, what I have found from > various > > sources is: > > > > GOMAXPROCS-number of threads are created to run Go-code, which used to > > default to 1, but now defaults to the number of processors (whatever the > > system shows as a processor) available to the machine. > > That is inaccurate. GOMAXPROCS is the number of threads that the Go > scheduler will schedule for simultaneous execution. It is the number > of threads that the Go scheduler will create. Normally there will be > more than GOMAXPROCS threads. > > > If the code requires a syscall or has the potential to block, another > thread > > is created for this. > > Approximately yes. A better way to describe it would be that if a > thread blocks in a syscall or C function, then a new thread will be > created in order to maintain the goal of having GOMAXPROCS threads > simultaneously executing Go code. > > > More thread(s) are created for GC > > Not really. Extra goroutines are created for GC, but they are > scheduled onto the threads like other goroutines. Also some GC work > is done by ordinary goroutines as they allocate memory. Various > mechanisms ensure that the GC gets enough CPU time to keep the program > from running out of memory. > > > All of this is probably system-dependent, and Go-version dependent as > well, > > so I know it's not the easiest thing to answer in a simple way. > > That is true, I'm describing the gc toolchain version 1.7. > > 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.
