Go 1.14 release notes

This means that the threads can't be blocked forever. The way Go scheduler work is to check during function calls if the current goroutine has executed for some period of time, after that the scheduler will remove the goroutine from the thread and open space for other goroutines to execute. But if you're doing a loop without function calls, imagine a for {}, in this case, the thread will be locked forever. Now with 1.14, this don't happen anymore. In my opinion the expected result will be better tail latencies.

It means the following program will happily exit now.

  package main
  
  import (
    "time"
    "runtime"
  )
  
  func main(){
    for i := runtime.NumCPU(); i > 0; i-- {
      go func() {
        for {}
      }()
    }
    time.Sleep(time.Second)
    println("bye")
  }

Go has supported running goroutines in parallel since before 1.0, and it’s been the default behaviour since version 1.5, released in 2015.

The download page (https://golang.org/dl/) shows 1.14 as the current version.

It looks like it has been released now.

Defers can happen in a loop, so you need a stack for correctness. This change is that the compiler will now automatically inline the defer-ed call so they appear much the same as a direct call at the end of a function if they happen at most once.

The full design doc is here: https://github.com/golang/proposal/blob/master/design/34481-...

> Go 1.13 implements the defer statement by calling into the runtime to push a "defer object" onto the defer chain. Then, in any function that contains defer statements, the compiler inserts a call to runtime.deferreturn at every function exit point to unwind that function's defers.

> We propose optimizing deferred calls in functions where every defer is executed at most once (specifically, a defer may be on a conditional path, but is never in a loop in the control-flow graph). In this optimization, the compiler assigns a bit for every defer site to indicate whether that defer had been reached or not. The defer statement itself simply sets the corresponding bit and stores all necessary arguments in specific stack slots. Then, at every exit point of the function, the compiler open-codes each deferred call, protected by (and clearing) each corresponding bit.

defer-ed calls are (in a very simplified way) pushed on a "stack" of methods to be called just before parent function exists. The mechanics of retrieval-call-repeat_if_more_available are cheap, but not free. They have reduced costs of these interactions.

> But maybe that's infeasible for deeply nested structs.

That's the crux of my issue. If it was only for a single, un-nested field then it would be trivial.

I am currently solving it by walking through the whole struct, but that is not-ideal.

They have checksum hashes but not crypto verifiable signatures.

Defense in depth, essentially. But yes, checking site X to see if site X gave you Y correctly is rather weak confidence.

To argue in its favor tho, file-hosting and site-serving may be handled by different systems with different security characteristics, and potentially even different datacenters (e.g. a CDN). If you only have to compromise one system, it's generally easier to do so than when you have to compromise N and make them all agree with each other.

If a hosting server is compromised the hash and download can be changed with something nefarious. crypto signing/verification will catch that case. hash checking will not.

This is a legitimate case as it's happened to other projects in the past.

Time flies when you're having fun ;-)