[libvirt] Redesigning Libvirt: Adopting use of a safe language

[Chris Friesen]

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