On 11/16/2017 03:55 PM, John Ferlan wrote:
On 11/14/2017 12:27 PM, Daniel P. Berrange wrote:
> Part of the problem is that, despite Linux having very low overhead
> thread spawning, threads still consume non-trivial resources, so we try to
> constrain how many we use, which forces an M:N relationship between jobs we need
> to process and threads we have available.
>
So GO's process/thread model is then lightweight? What did they learn
that the rest of us ought to know! Or is this just a continuation of the
libvirtd discussion?
Goroutines are not strictly 1:1 mapped to an OS thread...it's an N:M mapping
where a blocking call in a goroutine will not block any other goroutines.
Modern Go defaults to a number of OS threads equal to the number of cores.
Chris