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

[Chris Friesen]

On 11/17/2017 06:37 AM, Daniel P. Berrange wrote:
> On Fri, Nov 17, 2017 at 01:34:54PM +0100, Markus Armbruster wrote:
>> "Daniel P. Berrange" <berrange at redhat.com> writes:
>>
>> [...]
>>> Goroutines are basically a union of the thread + coroutine concepts. The
>>> Go runtime will create N OS level threads, where the default N currently
>>> matches the number of logical CPU cores you host has (but is tunable to
>>> other values). The application code just always creates Goroutines which
>>> are userspace threads just like coroutines. The Go runtime will dynamically
>>> switch goroutines at key points, and automatically pick suitable OS level
>>> threads to run them on to maximize concurrency. Most cleverly goroutines
>>> have a 2 KB default stack size, and runtime will dynamically grow the
>>> stack if that limit is reached.
>>
>> Does this work even when the stack limit is exceeded in a C function?
>
> When you make a C call in go, it runs in a separate stack. The goroutines
> own stack is managed by the garbage collector, so can't be exposed to C
> code. I'm unclear exactly what size the C stack would be, but it'll be
> the traditional fixed size, not the grow-on-demand behaviour of the Go
> stack.

Based on 
https://github.com/golang/go/blob/master/src/runtime/cgo/gcc_linux_amd64.c it 
looks like they don't explicitly specify a stack size, at least on linux.

Are there limits as to what you're allowed to do in C code called from Go?  Can 
you fork processes, spawn threads, call setjmp/longjmp, handle signals, sleep, etc.?

Chris