[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]