Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language
On Fri, Nov 17, 2017 at 10:04:35AM -0600, Chris Friesen wrote:
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(a)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.
That'll inherit the default from ulimit then, which will be 8MB
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.?
The big caveats are around sharing memory between the Go & C layers. You
generally need to copy data between the layers to avoid C code interacting
with Go memory that can be garbage collected.
In terms of whta C can do, I think pretty much anything is possible, within
the constraints of safe C programming - eg careful wrt async signal safety
as normal. You also have to be aware that if a C code called from goroutines
makes the goroutine much heavier than normal, because of the extra C stack
space. ie just because you can have 1000's of goroutines running go code,
doesn't mean you can have 1000's of goroutines running C code, as stack
size explodes from 2kb to 8 MB
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|