Navigation Menu

Skip to content

Instantly share code, notes, and snippets.

View go101's full-sized avatar

Go101 go101

View GitHub Profile
@go101
go101 / gist:338a7ae09d108171a677c38e93af2f39
Last active June 28, 2020 15:22
Use sync.RWMutex to slice write jobs
package main
import (
"fmt"
"math/rand"
"sync"
"time"
)
func main() {
@go101
go101 / panic-recover.txt
Created January 6, 2020 17:14
panic-recover mechanism explanations
Assume "returning phase" has been defined elsewhere in Go specificaiton.
At run time, a fucntion call may call other functions.
This forms a call stack at any time in each goroutine.
We call the top call in the stack as the current call.
Each non-existed call in the stack may associate with at most one panic.
At run time, panics may occur when the current call is being executed.
Panics occur either by calling the builtin panic fucntion or
performing operations that cause runtime panics.
@go101
go101 / cpp_bind
Created December 9, 2019 18:36
use C++ member functions as callbacks
#include <functional>
#include <iostream>
using namespace std;
class C
{
public:
int foo;
@go101
go101 / panic-recover-goexit-cases.md
Last active November 12, 2019 15:20
All kinds of Panic/recover/Goexit cases

A good panic/reover/Goexit explaination should cover these following cases.

  1. The program exits normally.
package main

func main() {
	defer func() {
		recover() // recover "bye"
@go101
go101 / panic-recover.md
Last active November 12, 2019 14:40
Panic.recover mechanism

(Update: I wrote a more formal article on this topic.)

At a time, there might be multiple unrecovered panics coexisting in a goroutine. Each one associates with one non-exited function call in the call stack of the goroutine. Each non-exited function call may associate with at most one unrecovered panic.

Similarly, at a time, there might be multiple Goexit signals coexisting in a goroutine. Each one associates