Re: Redesigning Libvirt: Adopting use of a safe language

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

 



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@xxxxxxxxxx> 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 :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux