Small Libraries

Go'Circuit

http://www.gocircuit.org/

feedback := make(chan int)
circuit.Spawn("host25.datacenter.net", func() {
    feedback <- 1
})
<-feedback
println("Roundtrip complete.")

Circuit

The circuit can be described as a distributed operating system that sits on top of the traditional OS on multiple machines in a datacenter deployment. It provides a clean and uniform abstraction for treating an entire hardware cluster as a single, monolithic compute resource. To do so, it provides:

A simple but flexible substrate for service registry and discovery, embodied by a virtual file system (See Anchor file system) of all live processes, as well as
A general-purpose networking metaphore that relieves application developers from concerns with networking peculiarities, while at the same time giving low-level engineers and operations personnel full freedom in designing network failure recovery algorithms, indepenently of application-level logic.

Circuit Runtime

import _ "circuit/load/cmd"

API packages

import "circuit/use/circuit"

Spawning a worker

Spawn(host circuit.Host, anchor []string, f circuit.Func, in ...interface{})
    (out []interface{}, addr circuit.Addr, err error)

circuit.Host - интерфейс, който позволява да ползваме различни идеи за "host"
anchor - списък от директории в "anchor file system".
Briefly, the anchor file system is akin to Linux' procfs, except that in our case it keeps track of all live workers across machines involved in a circuit application.

Worker functions

import "circuit/use/circuit"

type MyWorkerFunc struct{}

func (MyWorkerFunc) SingletonMethod(greeting string) (response string) {
    return "Hello " + greeting
}

func init() {
    circuit.RegisterFunc(MyWorkerFunc{})
}

Spawn semantics

(1) A new worker process is started on the desired host and a connection is established between the parent and child circuit runtimes.

(2) The worker (an OS-process) proceeds to:
(2a) Execute the desired worker function,
(2b) Send its return values back to the parent process, and
(2c) Die immediately after.

(3) The calling process receives the return values (or detects failure) and returns (unblocks) from the call to Spawn.

Daemonizing worker functions

import "circuit/use/circuit"

type StartServer struct{}

func (StartServer) Main() (hostport string, err error) {
    server, err := StartLocalWebServer()   // Bind a web server
    if err != nil {
        return "", err
    }
    go func() {                            // Start accepting requests in new goroutine
        for { server.AcceptNext() }
    }()
    return server.HostPort(), nil          // Communicate the URL of the server to the caller
}

func init() {
    circuit.RegisterFunc(StartServer{})
}

Daemonizing worker functions (fixed)

...
circuit.RunInBack(func() {
    for { server.AcceptNext() }
})
...

Communicating across workers

Всичко се подава по стойност
Any changes to values at the receiver will not be reflected at the sender. This is in line with standard Go semantics, except when dealing with slices or maps: In traditional Go, changes to the contents of a slice or a map will be reflected at the caller, since slices and maps are effectively pointer values. This is not the case in circuit cross-calls.
Channel and function values cannot be used as arguments or return values of functions that will be cross-called. They will raise a panic.

Cross-interfaces

The Circuit augments the Go language with an additional type, dubbed a cross-interface, that has the same semantic interpretation as a normal interface, with the difference that it can refer to an underlying object that lives in a process other than the currently executing one.
Semantically, one can think of circuit.X as “the interface{} of cross-interfaces”

Making cross-interfaces

Suppose we need to implemented a file system type, whose singleton method opens a local file and returns an object representing the open file. A typical Go implementation would like something like this:

func (fs *FileSystem) Open(name string) (*File, error) {
    …
    return file, nil
}

Now suppose we would like to be able to cross-call Open. If the implementation is left as is, the returned value *File will be flattened and serialized back to the caller. This is not what we want.

func (fs *FileSystem) Open(name string) (circuit.X, error) {
    …
    return circuit.Ref(file), nil
}

Using cross-interfaces

The native Go value circuit.X — which represents a cross-interface — provides a Call method for invoking the methods of the object underlying the cross-interface, wherever (remotely) it might be located.

Call(proc string, in ...interface{}) []interface{}

Cross-runtime garbage collection

What happens to the underlying objects that are solely referenced by cross-interfaces at remote workers that have died?

The short answer is: The right thing happens.

encoding/gob

gob!?

Binary values exchanged between an Encoder (transmitter) and a Decoder (receiver)

Нямат за цел да бъдат съвместими с каквото и да е, извън Go
Не зависят от нищо извън езика
Нямат нужда от допълнителна нотация (self-describing)
Ок е да си напишем наши encoder-и и decoder-и

gob стойности

Не е нужно да се пакетират в специална структура или да отговарят на някакъв интерфейс
Не дефинират типовете си изрично. Т.е. е в реда на нещата да изпратим int8, а получателят да декодира int32
Указателите се flat-ват
Encode-ват се само експортнатите стойности
Нулевите дори не се пращат, тъй като получателят ги знае, ако му трябват

Ако изпратим:

type T struct{ X, Y, Z int }
var t = T{X: 7, Y: 0, Z: 8}

Можем да ги получим като:

type U struct{ X, Y *int8 }

Какво точно се праща по мрежата

Дефиницията на даден тип се праща само първия път и се номерира по тип
След това просто се пращат стойности от тип това число

("define type id" 127, definition of type T)(127, T value)(127, T value), ...

При първо изпращане на стойност от даден тип се вдига малък интерпретатор за този тип
С малко reflection в началото се изготвят правилата, по които ще се encode-ва
След това енкодването е практически безплатно

При декодирането се случва нещо подобно

Какво правим, ако решим да си говорим с нещо различно от go?

json (the good)
xml (the bad)
csv (the ugly)

Очевидно ще си говорим за json от тук нататък.

Marshalling

The process of transforming the memory representation of an object to a data format suitable for storage or transmission

Някои му викат сериализация

Example

package main

import (
	"encoding/json"
	"fmt"
	"os"
)

func main() {
    type ColorGroup struct {
        ID     int `asdasdsad:",string"`
        Name   string
        Colors []string
    }
    group := ColorGroup{
        Name:   "Reds",
        Colors: []string{"Crimson", "Red", "Ruby", "Maroon"},
    }
    b, err := json.Marshal(group)
    if err != nil {
        fmt.Println("error:", err)
    }
    os.Stdout.Write(b)
}

Pros and Cons

Pros:

Мултиплатформен от всякъде
Лесен за четене
Лесен за писане, дори с обикновен текстови редактор

Cons:

Далеч по-бавен от gob
Канали, комплексни числа и функции не мога да се сериализират
map-ове могат, само ако ключовете им са стрингове
Не можем да сериализираме циклични данни

Field tags

Знаем, че се сериализират само експортнати стойности. Не можем ли да скрием някоя?
Знаем, че сериализраната стойност ще има същите име и тип. Не можем ли да ги променим?
Винаги ли трябва да подаваме дадена стойност, дори ако тя е празна?

На всяка стойност в strcut можем да прилагаме тагове за конкретен формат.

Field int `json:"-"` // Няма да бъде сериализрано
Field int `json:"myName,string"` // Ще бъде сериализрано като myName от тип string
Field int `json:",omitempty"` // Няма да бъде сериализирано, ако е празно

Unmarshal

Очевидно ако получим вече сериализиран json, можем да го десериализираме.

bool, for JSON booleans
float64, for JSON numbers
string, for JSON strings
[]interface{}, for JSON arrays
map[string]interface{}, for JSON objects
nil for JSON null

And now for something completely different

unsafe

Пакет, в стандартната библиотека, който съдържа няколко операции, заобикалящи type safety-то на езика.
Нямаме особено добра идея защо са ви...

func Alignof(v ArbitraryType) uintptr
func Offsetof(v ArbitraryType) uintptr
func Sizeof(v ArbitraryType) uintptr

sync/atomic

Съдържа примитиви от ниско ниво за разни операции, които сме сигурни, че са атомарни.

Функцията CompareAndSwapT е аналогична на:

if *addr == old {
    *addr = new
    return true
}
return false