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

[Daniel P. Berrange]

On Tue, Nov 28, 2017 at 08:43:54AM +0100, Martin Kletzander wrote:
> On Mon, Nov 20, 2017 at 04:57:56PM +0000, Daniel P. Berrange wrote:
> > On Mon, Nov 20, 2017 at 05:36:24PM +0100, Martin Kletzander wrote:
> > > On Mon, Nov 20, 2017 at 03:25:33PM +0000, Daniel P. Berrange wrote:
> > > >
> > > > I shouldn't have used the word "allocation" in my paragraph above. As
> > > > you say, both languages have similar needs around allocation. The difference
> > > > I meant is around deallocation policy - in Rust, object lifetime is is a more
> > > > explicit decision on control of the progammer, as opposed to Go's garbage
> > > > collection.  From what I've read Rust approach to deallocation is much
> > > > closer to the C++ concept of "smart pointers", eg this
> > > >
> > > >  http://pcwalton.github.io/blog/2013/03/18/an-overview-of-memory-management-in-rust/
> > > >
> > > 
> > > This is kind of old, that code wouldn't run with newer Rust.  I guess
> > > that is from far ago when it was not stabilized at all.  It is a bit
> > > smarter now.  The fact that you have control over when the value is
> > > getting freed is true, however you rarely have to think about that.
> > > What's more important is that the compiler prevents you from accessing
> > > value from multiple places or not knowing who "owns" (think of it as
> > > "who should take care of freeing it") the variable.  If you give the
> > > ownership to someone you can't access it.  The difference I see is that
> > > if you access it after some other part of the code is responsible for
> > > that variable in Rust the compiler will cut you off unless you clearly
> > > specify how the memory space related to the variable is supposed to be
> > > handled.  In Go it will just work (with potential bug) but it will not
> > > crash because GC will not clean it up when someone can still access it.
> > > Granted this is usually problem with concurrent threads/coroutines (which
> > > I don't know how they handle access concurrent access in Go).  Also, for
> > > example Rust doesn't allow you to have value accessible from multiple
> > > threads unless it is guarded by thread-safe reference counter and does
> > > not allow you to modify it unless it is guarded by Mutex, RWLock or s
> > > one of the Atomic types.  Again, I don't know Go that much, I'm still
> > > yet to delve into the deep unknowns of it, but I haven't heard about it
> > > providing such safety.
> > 
> > The example you give about Rust not permitting concurrent usage is
> > one of the unique features I alluded to that Go doesn't have.
> > 
> 
> Just a quick note on what I've found out after I dedicated half day to go
> through the tour of go and some other tutorials.  The learning curve of Go is
> even less steep than I though (for some unknown reason) it is.  So that's in
> favor of Go.  However I haven't found out how is it possible to avoid some
> SIGSEGVs or aborts since Go doesn't have many recoverable errors.  And in some
> cases they are not easy to spot immediately.  Or making sure struct fields are
> initialized.  Since libvirt strives to go for recoverable errors, I see this as
> a downside.

Either I'm mis-understanding what you mean, or you missed the 'recover'
function. In normal operation, error reporting is dealt with by having
functions return a value that implements the 'error' interface. Functions
can have multiple return values, so typically you would return a pair of
values, the first being the data, the second being the error indicator.
You check & deal with those errors with normal control flow statements.

For cases where the code triggered a runtime panic() (eg dereference a
Nil pointer), ordinarily that will terminate the program. At point in
the callstack, however, can catch that panic using the recover() method
which avoids termination, and resumes normal execution. Typically in an
RPC server, the RPC dispatch method would use recover() so that if any
RPC method execution  panic()s the server carries on running normally,
only that one method is terminated.

The only thing that you can't catch is when you call into C code and
that crashes. The C code can obviously arbitrarily corrupt memory, so
there's no safe way to recover that. Only the Go can be recover()d from.

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