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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list